Sécuriser OPC UA : passer du mode None aux certificats X.509
Dans la modernisation des architectures d’automatisme, la convergence entre le réseau d’opérations (OT) et le réseau informatique (IT) impose une protection rigoureuse des échanges de données. Le protocole OPC UA s’est imposé comme le standard d’interopérabilité sur les lignes de production, assurant le dialogue entre automates programmables, superviseurs SCADA et systèmes MES. Cependant, lors des phases de mise en service, de nombreux projets conservent par facilité la politique de sécurité configurée sur “None/None”. Ce choix laisse les flux industriels circuler en clair sur le réseau, exposant les installations aux risques d’écoute clandestine, de falsification de données ou d’usurpation d’identité. Pour se conformer aux exigences de la norme IEC 62443, la transition vers un environnement sécurisé reposant sur des certificats X.509 et des gestionnaires de certificats constitue une étape indispensable.
Du mode None à la protection des flux industriels
La configuration “None/None” signifie qu’aucun chiffrement ni aucune authentification d’application ne sont appliqués aux messages OPC UA. Un équipement tiers branché sur le même VLAN peut alors lire le contenu de la table d’échange ou injecter des valeurs modifiées vers un serveur OPC UA.
Pour supprimer ce vecteur de risque, le standard OPC UA définit plusieurs politiques de sécurité qui combinent la signature numérique et le chiffrement des données. Lors de l’établissement du canal de communication, l’association du mode “SignAndEncrypt” avec des algorithmes robustes comme Basic256Sha256 ou Aes256_Sha256_RsaPss garantit deux éléments fondamentaux :
- L’intégrité et la confidentialité des messages : le payload est chiffré via AES et signé numériquement (HMAC-SHA256), garantissant la confidentialité et empêchant l’altération des données.
- L’authentification mutuelle des applications : chaque participant apporte la preuve de son identité avant l’ouverture de la session.
Le choix du niveau de sécurité dépend des capacités de calcul des équipements installés. Si les contrôleurs récents gèrent le chiffrement asymétrique sans dégrader leurs temps de cycle, les appareils plus anciens peuvent nécessiter des adaptations de leur charge de traitement.
Le rôle central des certificats X.509 et de la PKI
Le mécanisme de confiance d’OPC UA repose sur une infrastructure à clés publiques (ou PKI). Chaque client et serveur OPC UA possède une carte d’identité numérique matérialisée par un certificat électronique X.509 v3. Ce document contient la clé publique de l’application, sa clé privée restant jalousement conservée dans un magasin sécurisé sur l’équipement.
Lors de la poignée de main initiale (handshake), les deux équipements s’échangent leurs certificats respectifs. La validation s’effectue selon deux architectures distinctes :
- Les certificats auto-signés : chaque équipement génère son propre certificat. L’administrateur doit extraire manuellement le certificat du client pour le déposer dans le dossier des certificats de confiance (Trusted Store) du serveur, et inversement. Si l’émetteur est inconnu, le certificat est dirigé vers le dossier des rejets (Rejected Store) jusqu’à validation manuelle.
- Les certificats signés par une autorité de certification (CA) : les équipements font confiance à une autorité racine commune. Tout certificat émis et signé par cette CA est automatiquement validé par les participants, simplifiant grandement le déploiement sur les architectures comportant des dizaines de serveurs.
Contactez nos experts pour déployer les certificats X.509 et le mode SignAndEncrypt.
Automatisation et gestion des clés avec le serveur GDS
L’administration manuelle de fichiers de certificats montre rapidement ses limites lors du passage à l’échelle. Dans une usine hébergeant une cinquantaine d’automates et plusieurs superviseurs, la gestion individuelle des listes de confiance devient une tâche chronophage et sujette aux erreurs humaines.
Pour résoudre cette difficulté, l’OPC Foundation a intégré la spécification du Global Discovery Server (GDS). Ce composant agit comme un serveur central de gestion du cycle de vie des certificats. Grâce au service “GDS Push”, le serveur central est capable de :
- Déployer automatiquement les nouveaux certificats X.509 sur les équipements cibles sans interruption de service.
- Renouveler les certificats arrivant à échéance avant leur date d’expiration.
- Distribuer les listes de révocation (CRL) pour bloquer immédiatement un équipement compromis ou retiré du réseau.
Cette centralisation garantit le maintien de la politique de sécurité globale tout en réduisant la charge de maintenance des équipes d’automatisme.
Exemples
Dans le cadre de la refonte d’un atelier d’assemblage automobile comportant 30 automates Siemens S7-1500, 4 cellules robotisées et un système SCADA central, la liaison OPC UA initiale fonctionnait en mode “None/None”. L’objectif consistait à sécuriser l’ensemble des conduits de communication sans bloquer la production.
La démarche s’est déroulée en trois étapes. Tout d’abord, la création d’une autorité de certification interne dédiée au réseau OT a permis d’émettre des certificats X.509 spécifiques à chaque équipement. Ensuite, les ingénieurs ont configuré les points d’accès OPC UA des automates pour accepter uniquement le profil SignAndEncrypt avec la politique Aes256_Sha256_RsaPss. Enfin, le déploiement d’un gestionnaire GDS sur le réseau de supervision a automatisé la distribution des listes de confiance.
Cette transition a permis de sécuriser 100 % des flux de données de l’atelier tout en conservant une période de rafraîchissement des variables inférieure à 50 millisecondes.
Limites et contraintes
La mise en œuvre de certificats électroniques en environnement industriel comporte plusieurs contraintes opérationnelles qu’il convient d’anticiper :
- Le risque d’arrêt de production par expiration : un certificat arrivé à date de fin d’activité sans renouvellement préalable entraîne un refus instantané de connexion par le serveur OPC UA. Sans gestionnaire automatique, une ligne de fabrication peut se trouver bloquée.
- La charge processeur des automates compacts : le chiffrement asymétrique lors du handshake demande des ressources de calcul. Sur les petits contrôleurs d’ancienne génération, cela peut allonger le temps d’établissement des liaisons.
- La gestion de la date et de l’heure : la vérification de la validité d’un certificat X.509 nécessite une synchronisation temporelle précise (via un serveur NTP industriel). Une dérive d’horloge sur un automate peut invalider à tort un certificat parfaitement conforme.
Conclusion
Abandonner le mode “None/None” pour adopter une architecture OPC UA sécurisée par des certificats X.509 n’est plus une option mais une nécessité pour la cybersécurité des usines. En combinant le chiffrement fort et la gestion centralisée par serveur GDS, vous protégez vos données industrielles tout en pérennisant votre infrastructure face aux exigences de la norme IEC 62443. La clé du succès réside dans une mise en place progressive, en commençant par l’inventaire des flux et la synchronisation temporelle des équipements.
