Un automate programmable (PLC) hérité accepte toute connexion sur son port ouvert. Il n'a aucune notion d'utilisateurs, de rôles ou de sessions. Il ne peut pas enregistrer qui y a accédé ni quand. Il transmet en clair. Il a été conçu ainsi parce qu'au moment de sa fabrication, le réseau sur lequel il fonctionnait était physiquement isolé. Cette hypothèse ne tient plus.
L'architecture lollipop résout ce problème en plaçant un proxy à reconnaissance d'identité devant chaque PLC. Le proxy prend en charge tout ce que le PLC ne peut pas faire : authentification, autorisation, journalisation et chiffrement. Le PLC continue de fonctionner exactement comme avant. Il ne sait pas que le proxy existe.
À quoi ressemble le lollipop
Imaginez chaque actif OT comme un bonbon au bout d'un bâton. Le bonbon est l'actif (PLC, CNC, HMI). Le bâton est l'unique chemin imposé à travers le proxy. Il n'existe aucun autre chemin. Pas de connexions latérales entre les actifs. Pas d'accès direct depuis le réseau.
User → [MFA] → [Proxy] → PLC
↓
[Session Log]
Chaque connexion au PLC doit :
- Authentifier l'utilisateur (MFA au niveau du proxy)
- Vérifier l'autorisation (rôle, actif, protocole, fenêtre temporelle)
- Établir une session journalisée (identité de l'utilisateur, horodatage, charge utile)
- Chiffrer le segment utilisateur-proxy (TLS)
Le segment proxy-PLC utilise le protocole industriel natif (Modbus, EtherNet/IP, OPC UA). Le PLC reçoit exactement ce qu'il attend. Aucune traduction de protocole. Aucune modification du firmware.
Déploiement
L'appliance ou la VM Access Gate se connecte en adjacence au réseau existant. Elle ne s'insère pas en coupure dans le trafic de production. Elle crée un réseau superposé (overlay) utilisant la plage d'adresses 100.64.0.0/16.
Pour chaque actif OT, l'Access Gate crée un point de terminaison proxy. L'overlay achemine tout le trafic vers cet actif via son proxy. L'adresse IP d'origine et la configuration des commutateurs restent inchangées.
Le déploiement se compte en heures, pas en semaines. Connectez l'appliance, découvrez les actifs, définissez les politiques, appliquez-les. Pas de reconfiguration de VLAN. Pas de recâblage. Pas de modification d'adresses IP. Pas d'interruption de la production.
Ce que le proxy applique
Vérification d'identité
Avant qu'une session atteigne le PLC, l'utilisateur doit s'authentifier via la passerelle d'identité de l'Access Gate. Nom d'utilisateur, mot de passe et jeton TOTP. Le PLC ne reçoit jamais de trafic non authentifié.
Contrôle d'accès basé sur les rôles
Tous les utilisateurs ne doivent pas accéder à tous les PLC. Un fournisseur OEM obtient l'accès au CNC spécifique qu'il entretient, sur le protocole spécifique dont il a besoin, pendant la fenêtre de maintenance définie. Un opérateur accède au HMI, pas au PLC qui se trouve derrière. Les politiques définissent qui peut accéder à quoi.
Journalisation des sessions
Chaque connexion est enregistrée avec : l'identité de l'utilisateur, l'IP source, l'actif de destination, le protocole, la charge utile des commandes, l'horodatage et la durée de session. C'est la piste d'audit qu'exige CMMC AU 3.3.1 et que le PLC ne peut pas générer par lui-même.
Refus par défaut
Si aucune politique n'autorise une connexion, celle-ci est bloquée et journalisée. Cela inverse le modèle de réseau à plat où tout peut atteindre tout. Avec l'architecture lollipop, rien n'atteint quoi que ce soit sans autorisation explicite.
Chiffrement
Le segment entre l'utilisateur et le proxy est chiffré avec TLS. Le segment entre le proxy et le PLC utilise le protocole natif en clair, mais ce segment est isolé dans une micro-DMZ sans sortie externe. Les CUI en transit sont protégées.
Pourquoi « lollipop » et non « hub and spoke »
Le modèle hub and spoke implique des chemins latéraux entre les branches via le hub. Le modèle lollipop est plus strict. Chaque actif dispose d'un unique chemin imposé. Il n'existe aucune connectivité entre les actifs à moins qu'une politique ne la crée explicitement. Cela élimine les mouvements latéraux par conception.
Si un attaquant compromet un PLC (par accès physique ou via une faille zero-day dans le protocole), il ne peut atteindre aucun autre actif. La topologie overlay bloque tous les chemins latéraux. L'attaquant est confiné dans un segment d'un seul élément.
Positionnement dans les référentiels de conformité
| Référentiel | Exigence | Ce que le lollipop couvre |
|---|---|---|
| CMMC | Contrôle d'accès (AC) | Autorisation basée sur l'identité par session |
| CMMC | Journalisation d'audit (AU) | Journalisation des sessions avec identité de l'utilisateur |
| CMMC | Chiffrement (SC) | TLS sur les chemins CUI |
| NIS2 | Segmentation réseau | Microsegmentation par actif |
| IEC 62443 | Zone et conduit | Chaque proxy constitue une frontière de conduit |
Le livre blanc Modèles de conception de DMZ industrielle couvre en détail les quatre modèles d'architecture, dont le modèle lollipop (médiation en ligne).
Pour davantage de ressources Zero Trust OT, des guides d'architecture et des comparaisons, consultez le hub Zero Trust pour les réseaux OT.
