Sécurité & certificats OPC UA
La sécurité est intégrée à OPC UA, pas rajoutée par-dessus. Une connexion négocie une politique de sécurité et un mode, puis client et serveur s'authentifient mutuellement avec des certificats X.509. Comprendre ces deux notions (modes et confiance) résout la plupart des questions de sécurité et des échecs de connexion.
Les quatre piliers
| Pilier | Ce qu'elle protège |
|---|---|
| Chiffrement | Confidentialité: personne ne peut lire le trafic |
| Signature | Intégrité: les messages ne peuvent pas être altérés |
| Authentification | Identité, de l'application (certificat) et de l'utilisateur |
| Autorisation | Droits: ce qu'un utilisateur authentifié peut faire |
Modes de sécurité
- None, pas de signature ni de chiffrement. Uniquement pour des tests isolés.
- Sign: les messages sont signés (intégrité + authenticité) mais pas chiffrés.
- Sign & Encrypt: signé et chiffré. À utiliser en production.
Chaque mode va de pair avec une politique de sécurité (la suite cryptographique, par exemple Basic256Sha256 ou les politiques Aes256 plus récentes). Préférez les politiques modernes et désactivez celles qui sont dépréciées.
Comment fonctionne l'approbation des certificats
Chaque application OPC UA possède son propre certificat d'instance. À la connexion, client et serveur échangent leurs certificats; chacun tient un petit magasin PKI:
pki/
├─ own/ # this application's own cert + private key
├─ trusted/certs # certificates we trust
├─ trusted/crl # certificate revocation lists
├─ issuer/ # CA certs (if using a CA)
└─ rejected/ # certs seen but not yet trustedrejected/. Déplacez-le verstrusted/certsdes deux côtés, puis reconnectez-vous. Cette seule étape résout la plupart des erreurs « BadSecurityChecksFailed ».Auto-signé vs signé par une CA
Les certificats auto-signés conviennent aux déploiements petits et statiques: vous approuvez chacun d'eux manuellement. Pour un parc, une autorité de certification (ou le GDS OPC UA: Global Discovery Server) met la confiance à l'échelle: vous approuvez l'autorité une fois et tous les certificats qu'elle émet sont approuvés automatiquement.
Authentification utilisateur
L'identité applicative (certificat) est distincte de l'identité utilisateur. Un serveur peut accepter des jetons anonymes, nom d'utilisateur / mot de passe ou certificat utilisateur. Alignez-vous sur ce qu'attend le serveur, et préférez des utilisateurs nommés à l'anonyme en production, pour que les actions soient imputables.
Check-list de durcissement
- Utilisez Sign & Encrypt avec une politique moderne; désactivez None et les politiques dépréciées.
- Remplacez les certificats par défaut ou auto-signés par des certificats gérés; définissez une expiration sensée et faites la rotation.
- Exigez des utilisateurs nommés; désactivez l'anonyme si possible.
- Appliquez le moindre privilège: lecture seule sauf si l'écriture est vraiment nécessaire.
- Maintenez les CRL à jour; retirez les certificats périmés de
trusted/. - Placez OPC UA sur un réseau segmenté; restreignez le port aux clients connus.
- Mettez à jour votre pile OPC UA: traitez-la comme n'importe quel autre service en réseau.
Dernière mise à jour le 4 septembre 2026 · Ressource pédagogique.