La plupart des équipements industriels embarquent une interface web, l'HMI intégré d'un PLC, la page de configuration d'un variateur, un tableau de bord de gestion de bâtiment. Beaucoup communiquent en HTTP en clair sur le port 80, 8080 ou similaire, sans authentification réelle, et ceux qui proposent du HTTPS servent souvent un certificat expiré ou auto-signé que le navigateur refuse. Access Gate place l'identité et le chiffrement devant ces interfaces sans toucher à l'équipement. Deux décisions structurent la configuration : comment le TLS est terminé, et si une connexion s'intercale devant l'application.
Comment la gate sécurise une interface web
Access Gate est un proxy conscient du protocole : le navigateur se connecte à la gate, la gate applique l'identité et la politique, puis se connecte à son tour à l'équipement. Comme la session est terminée au niveau de la gate, celle-ci peut présenter à l'utilisateur un certificat propre et de confiance, quel que soit le comportement de l'équipement de son côté, et elle peut exiger une authentification avant même que l'application soit accessible. L'équipement reste exactement tel qu'il est, HTTP en clair compris.
Décision 1 : comment le TLS est terminé
Il existe trois modes utiles, par ordre décroissant de fréquence pour les équipements industriels :
- Terminer et transmettre en clair. Le navigateur obtient du HTTPS vers la gate ; la gate parle le HTTP natif de l'équipement côté protégé. C'est le mode par défaut pour un équipement qui ne parle qu'HTTP en clair. Les identifiants et les cookies de session ne transitent plus en clair sur le réseau, et l'équipement n'a besoin d'aucune capacité cryptographique propre.
- Terminer et rechiffrer. L'équipement sert déjà du HTTPS (souvent avec un certificat auto-signé). La gate s'y connecte en HTTPS côté protégé, et les utilisateurs voient toujours le certificat de confiance de la gate, pas celui de l'équipement. Utilisez ce mode lorsque le segment protégé doit lui aussi être chiffré.
- Passthrough. La gate applique l'accessibilité et l'identité mais ne termine pas le TLS ; le navigateur négocie le TLS directement avec l'équipement. N'utilisez ce mode que lorsque le certificat de l'équipement est déjà de confiance.
Décision 2 : une connexion s'intercale-t-elle ?
- Via l'access screen. Exigez que l'utilisateur s'authentifie sur un access screen avant que l'application web soit accessible. C'est le bon choix par défaut pour tout HMI doté d'une authentification faible ou partagée au niveau de l'équipement, il place une identité réelle devant une page qui n'en a pas.
- Passthrough. Évitez l'écran lorsque l'application dispose de sa propre authentification adéquate et que vous n'avez besoin que de chiffrement et de contrôle réseau.
Configuration
- Ajoutez l'asset à une enclave, voir Protéger un asset avec les enclaves.
- Dans Enclaves → [Your Enclave] → Access Control, ajoutez une règle
allow. - Sélectionnez le principal (utilisateur, groupe IdP ou rôle) et le ou les assets, puis sauvegardez.
- Choisissez le mode TLS (terminer, rechiffrer ou passthrough) et décidez si un access screen s'intercale en amont.
- Dirigez les utilisateurs vers l'URL de l'asset ou son IP overlay.
Vous pouvez utiliser Access Gate pour ajouter une couche d'identité et de chiffrement devant une application qui ne parle qu'en clair, en combinant un access screen avec le chiffrement TLS.
Particularités des HMIs embarqués
Les interfaces web industrielles sont rarement conçues pour s'exécuter derrière un proxy. Les écueils récurrents :
- Liens
http://<ip>codés en dur. Certains HMIs embarquent des URL absolues qui pointent directement vers l'IP de l'équipement, contournant la gate. Atteindre l'application via le nom ou l'IP overlay, plutôt que l'adresse brute de l'équipement, maintient ces liens à l'intérieur du chemin intermédié. - Contenu mixte. Une page servie en HTTPS qui charge des scripts ou des images via du HTTP en clair est bloquée par le navigateur. Terminer le TLS au niveau de la gate alors que l'équipement reste en HTTP peut faire apparaître ce problème ; atteindre les assets via le même chemin overlay évite cette incohérence.
- WebSockets. Les tableaux de bord temps réel et les clients web SCADA utilisent souvent des WebSockets (
ws://ouwss://). Ils empruntent la même autorisation HTTP(S), mais vérifiez que l'upgrade est autorisé de bout en bout si un tableau de bord cesse de se mettre à jour. - Certificats auto-signés sur l'équipement. Si l'équipement sert du HTTPS avec un certificat auto-signé, le mode terminer-et-rechiffrer permet à la gate de se connecter côté protégé tandis que les utilisateurs voient toujours le certificat de confiance de la gate.
Récapitulatif
Vous avez publié un HMI web ou une page d'administration d'équipement via une enclave, choisi comment le TLS est terminé (transmission en clair, rechiffrement ou passthrough), et décidé si un access screen authentifie d'abord l'utilisateur, de sorte qu'un équipement legacy se voie doté de chiffrement et d'identité devant lui sans aucune modification de son côté.
Optez pour cette approche dès qu'un équipement industriel expose une interface HTTP en clair ou auto-signée avec une authentification faible, et que vous avez besoin de chiffrement et de contrôle d'accès sans modifier l'équipement.