Problématiques ouvertes et pistes

Note d'analyse. Chaque section expose une problématique et propose une ou plusieurs pistes de solution, avec une recommandation. Il ne s'agit pas d'un état des lieux figé mais d'un support de décision.

Documents de référence associés : ARCHITECTURE, NOTICE_TECHNIQUE, DIMENSIONNEMENT, MODBUS, dossier CRA.

1. Déploiement et exploitation

1.1 Accès distant à un poste isolé

Problématique. Le poste d'exploitation est raccordé au réseau local des centrales (Ethernet et série) et n'est pas connecté à Internet. La prise en main à distance (support, mise à jour, diagnostic) doit rester possible sans exposer le reste du poste à Internet, et sans dégrader la sécurité d'un système critique.

Piste A — accès hors-bande matériel (recommandée). Un boîtier de type IP-KVM (KVM sur IP) raccordé en HDMI et USB au poste, disposant de sa propre connectivité (lien cellulaire dédié ou VLAN d'administration isolé).

• Le poste reste totalement isolé : aucun logiciel d'accès, aucune route Internet, aucune surface d'attaque ajoutée à l'OS de supervision.
• La prise en main s'effectue au niveau écran/clavier, y compris avant démarrage de l'OS.
• Le chemin d'administration est physiquement séparé de l'OS et du réseau des centrales.
• Contrepartie : matériel dédié et un lien de connectivité distinct.

Piste B — accès logiciel à sortie verrouillée. Un unique tunnel sortant, cloisonné au pare-feu :

• VPN (par exemple WireGuard) lié à un point d'accès d'administration précis, puis bureau à distance (RDP ou VNC) dans le tunnel. Alternative auto-hébergée sans service tiers pour la prise en main.
• Pare-feu Windows en refus sortant par défaut, avec une seule exception pour le processus du tunnel vers l'adresse et le port du concentrateur. Le reste du poste demeure sans accès Internet.
• Contrepartie : surface logicielle non nulle sur le poste, à durcir (authentification forte, accès non surveillé désactivé au repos, journalisation).

Recommandation. Pour un poste critique isolé, privilégier la piste A (hors-bande). Retenir la piste B si un boîtier n'est pas envisageable, avec verrouillage strict de la sortie réseau.

1.2 Mises à jour

Problématique. L'installation et la mise à jour requièrent des droits administrateur (installation en Program Files, services Windows, certificat, pare-feu). Sur un parc de postes verrouillés, l'élévation à chaque mise à jour est contraignante.

Pistes.

• Déploiement managé (recommandé) : diffusion silencieuse de l'installateur (/VERYSILENT) via l'outillage d'entreprise (Intune, SCCM, GPO), appliquée avec les droits système. L'utilisateur ne voit aucune invite. En mode silencieux, prévoir le passage du mot de passe SuperAdmin par paramètre ou fichier de réponse, la page de saisie n'étant pas affichée.
• Canal d'administration existant : appliquer les mises à jour via la prise en main distante retenue en 1.1 (IP-KVM ou RDP).
• Service de mise à jour élevé (installé une fois) qui applique les mises à jour sans invite répétée : efficace mais représente un développement conséquent (canal signé, retour arrière).

1.3 Matériel et stockage

Spécifications du poste, budget de stockage et réglages PostgreSQL : voir DIMENSIONNEMENT. Points de vigilance : disque SSD, onduleur pour un fonctionnement continu, surveillance de l'espace libre.

2. Sécurité et conformité CRA

Problématique. Système critique soumis à des exigences réglementaires (CRA). L'ajout de fonctions d'exploitation (accès distant, mises à jour) doit préserver la surface d'attaque minimale et la traçabilité.

Acquis (voir l'évaluation des risques) : contrôle d'accès par rôles appliqué côté service, journal d'audit inaltérable conservé cinq ans, secrets protégés au repos, transport chiffré, durcissement des en-têtes.

Pistes.

• Cloisonner le canal d'accès distant du réseau des centrales (aucun pont entre les deux segments).
• Accès distant nominatif, à authentification forte, activé au besoin et tracé.
• Poursuivre l'analyse d'écart CRA au fil des versions plutôt qu'en fin de cycle.

3. Centrales reliées (côté terrain)

Problématique. La supervision dépend de la fiabilité des liaisons Modbus (TCP et série) et du comportement réel des firmwares (latence, effets de bord d'adressage). Une liaison instable ou une centrale mal câblée dégrade la remontée d'incidents.

Pistes.

• Segmenter le réseau des centrales et le séparer du réseau d'administration.
• Surveiller l'état des liaisons (l'application remonte déjà les défauts de liaison et la télémétrie Modbus).
• Vérifier l'adressage à la mise en service avec le scanner Modbus et la campagne de validation JBUS (voir §4).

4. Modbus et adressage

Problématique. Les firmwares présentent des divergences d'adressage par rapport au cahier des charges (décalages par bloc), sources d'erreurs de mapping à l'installation.

Pistes. L'application fait autorité sur l'adressage via une source unique de profils, et fournit des outils de vérification (scanner de registres, campagne de validation JBUS). Détail du protocole et des divergences : MODBUS ; état des compensations : COMPENSATIONS-MODBUS.