OPC UA est le protocole que les équipements industriels utilisent pour communiquer avec les logiciels, et tel que le terrain l'exploite, il est presque toujours joignable, en clair et non authentifié. Access Gate place identité, politique et chiffrement devant un serveur OPC UA sans modifier le serveur ni le client. Cette page explique brièvement le protocole, puis déroule un guide de bout en bout qui prend un serveur exposé et le sécurise.
Présentation d'OPC UA
OPC UA (Open Platform Communications Unified Architecture) est le protocole standard que les équipements industriels utilisent pour communiquer avec les logiciels. Un automate pilotant une pompe, un capteur lisant le niveau d'une cuve, un variateur de moteur, un système SCADA, un historien : tout cela parle OPC UA pour échanger des données. C'est la lingua franca de l'atelier, des stations d'eau, des sites énergétiques et des environnements OT en général.
Un serveur, généralement placé sur ou près de l'équipement (comme une instance KEPServerEX), expose un espace d'adressage : un arbre de nœuds représentant des valeurs réelles. Chaque tag, comme Motor1.RPM ou Tank1.Level_pct, est un nœud que vous pouvez lire, et souvent écrire. Les clients (ordinateurs d'ingénierie, SCADA, tableaux de bord) se connectent en TCP, généralement sur le port 4840, pour lire ces valeurs, s'abonner aux changements en direct ou écrire de nouvelles consignes.
Pour comprendre comment OPC UA chiffre le trafic et la différence entre ses deux mécanismes de sécurité, voir Le rôle de TLS dans la sécurisation d'OPC UA.
Guide de bout en bout : sécuriser un serveur OPC UA non sécurisé
Ceci est une démonstration en plusieurs étapes qui prend un serveur OPC UA non sécurisé (KEPServerEX, SecurityPolicy=None, anonyme) et montre comment Access Gate le protège sans toucher au serveur ni au client hérités. Elle se déroule en deux actes fixes, puis bifurque vers l'un des trois chemins de l'Acte 3 selon ce que le client et le Gate prennent en charge.
Points de terminaison et tags utilisés tout au long :
EP_DIRECT = opc.tcp://172.31.144.41:4840/kepware/ (serveur brut, underlay)
EP_GATE = opc.tcp://kepware.bluelab.ts-sec.net:4840/kepware/ (via l'enclave, par nom)
RPM = ns=2;i=2 Motor1.RPM
TEMP = ns=2;i=3 Motor1.Temp_C
TANK = ns=2;i=4 Tank1.Level_pct
ROOT_CA = ~/Downloads/troutzt_root.cert (racine Trout Access Gate)
Acte 1 : l'exposition (underlay, aucune protection)
Le serveur tel que le terrain l'exploite : joignable, en clair, anonyme, inscriptible.
export EP="opc.tcp://172.31.144.41:4840/kepware/"
echo ">>> Parcourir le serveur sans identifiants"
uabrowse -u "$EP" -v ERROR
echo ">>> Lire une consigne en direct"
uaread -u "$EP" -n "ns=2;i=4" -v ERROR
echo ">>> Écrire une nouvelle valeur sans authentification"
uawrite -u "$EP" -n "ns=2;i=4" 50.0 -v ERROR
uaread -u "$EP" -n "ns=2;i=4" -v ERROR
Quiconque peut atteindre le port 4840 lit toutes les valeurs et déplace les consignes. Pas de nom d'utilisateur, pas de certificat. Le protocole prend en charge la sécurité ; elle n'est simplement pas activée.
Acte 2 : créer l'enclave (overlay)
Placez le serveur dans une enclave Access Gate pour qu'il ne soit joignable que via l'overlay, par nom, pour une identité autorisée. Le serveur hérité reste inchangé.
export EPG="opc.tcp://kepware.bluelab.ts-sec.net:4840/kepware/"
echo ">>> Même serveur, désormais atteint via l'enclave par nom"
uaread -u "$EPG" -n "ns=2;i=2" -v ERROR
uabrowse -u "$EPG" -v ERROR
Rien sur l'automate ni sur le serveur n'a changé. Le serveur se trouve désormais derrière le Gate, joignable via l'overlay plutôt que sur le réseau à plat. L'accès est contrôlé par identité et journalisé.
Acte 3 : sécuriser le canal (choisissez un seul chemin)
Les trois chemins ci-dessous sont mutuellement exclusifs. Un client donné en utilise exactement un, selon ce que le client et le Gate prennent en charge. Décidez à l'avance et n'exécutez que ce chemin.
Chemin A : tunnel TLS (le client parle TLS, montrer le PQC)
À utiliser quand le client peut terminer TLS vers le Gate, ou que vous placez un terminateur TLS local sur la machine cliente pour que le segment en clair ne quitte jamais l'hôte.
Vérifiez le point de terminaison TLS du Gate :
openssl s_client -connect kepware.bluelab.ts-sec.net:4840 \
-servername kepware.bluelab.ts-sec.net \
-CAfile ~/Downloads/troutzt_root.cert </dev/null 2>&1 | \
grep -E "Verify return code|Negotiated TLS|Protocol|issuer="
Le canal vers le Gate est en TLS 1.3 avec échange de clés post-quantique (ML-KEM-768), vérifié contre notre propre PKI, devant un automate qui ne parle rien de tout cela. Pour savoir comment le Gate provisionne les certificats, négocie les suites de chiffrement et impose une politique « TLS uniquement », voir Configurer le chiffrement TLS. OPC UA définit aussi ses propres mappings basés sur TLS (opc.https et opc.wss) dans le standard, voir Le rôle de TLS dans la sécurisation d'OPC UA pour la comparaison.
Quand choisir A : l'argument du TLS post-quantique est l'élément phare, et vous acceptez un terminateur local (ou disposez d'un client réellement compatible TLS).
Chemin B : sécurité de message OPC UA
À utiliser quand vous voulez que n'importe quel client OPC UA standard se connecte de façon sécurisée, sans modification ni terminateur. Ici, le chiffrement a lieu au niveau du message OPC UA plutôt que dans un tunnel TLS, et Access Gate fournit la connectivité DNS, les contrôles ACL et la journalisation autour.
La sécurité de message OPC UA s'exécute à l'intérieur du SecureChannel du protocole. Pour l'activer, réglez les deux extrémités sur une politique de sécurité actuelle et un mode de sécurité de message :
- Politique de sécurité :
Basic256Sha256(ou une politiqueAes*plus récente si les deux extrémités la prennent en charge). Évitez les politiques obsolètesBasic128Rsa15etBasic256. - Mode de sécurité de message :
SignAndEncrypt.Signseul prouve l'intégrité mais laisse la charge utile lisible ; seulSignAndEncryptapporte la confidentialité. - Certificats : client et serveur échangent des certificats d'instance d'application X.509 et vérifient chacun celui de l'autre par rapport à leur liste de confiance, de sorte que le canal est mutuellement authentifié. Faites confiance au certificat du Gate côté client et au certificat du client côté Gate.
Le chiffrement repose ici sur RSA et AES selon la suite SecurityPolicy choisie, natif du standard et mutuellement authentifié, et non sur la suite TLS post-quantique du Chemin A.
Quand choisir B : votre serveur et votre client prennent en charge la sécurité de message OPC UA et pas TLS, et vous voulez un canal natif du standard et mutuellement authentifié, sans terminateur.
Chemin C : tunnel en clair via le Gate (repli)
À utiliser quand le client ne sait pas faire TLS et que le client et le serveur ne peuvent pas terminer un SecureChannel OPC UA. Le Gate transporte la session. Le client parle opc.tcp en clair au point de terminaison de l'enclave, sans modification.
Même sans aucune cryptographie côté client ou au niveau message, le serveur n'est plus sur le réseau ouvert. L'atteindre exige d'être une identité autorisée sur l'overlay, et chaque session est contrôlée et journalisée. C'est la posture minimale : contrôle d'accès et audit via l'enclave, sans changer le client ni le serveur hérités.
Récapitulatif
Vous avez pris un serveur OPC UA exposé, l'avez placé dans une enclave pour qu'il ne soit joignable que par une identité autorisée via l'overlay, puis sécurisé le canal avec l'une des trois options : un tunnel TLS post-quantique (Chemin A), la sécurité de message OPC UA native du standard (Chemin B) ou un tunnel en clair contrôlé qui apporte tout de même contrôle d'accès et audit (Chemin C). Le serveur et le client hérités n'ont jamais été modifiés.
Adoptez cette approche quand un serveur OPC UA est joignable, en clair et anonyme sur le réseau, et que vous devez placer identité, chiffrement et journalisation devant lui sans toucher à l'équipement.