SSH est le protocole pour le shell distant sécurisé et le transfert de fichiers. Il fonctionne sur une large gamme d'équipements, des serveurs et du matériel réseau aux passerelles et contrôleurs embarqués courants en OT (une passerelle MOXA dans cet exemple). Le canal est déjà chiffré de bout en bout, de sorte que le problème que pose SSH sur un réseau OT relève rarement de la confidentialité. Il s'agit de deux autres choses : la joignabilité à plat (tout ce qui se trouve sur le LAN peut frapper au port 22) et la prolifération des identifiants (des appareils sécurisés par une unique clé ou un mot de passe partagé, difficile à faire tourner). Access Gate répond aux deux, et offre deux façons distinctes de le faire.
Comment fonctionne réellement la sécurité SSH
Trois éléments entrent en jeu sur chaque session SSH, et ils échouent indépendamment :
- Clé d'hôte (identité du serveur). À la première connexion, le client enregistre la clé d'hôte du serveur. C'est ce qui empêche un homme du milieu, et c'est aussi ce qui produit l'avertissement « la clé d'hôte a changé » que les opérateurs sont habitués à ignorer d'un clic. La gate, en médiant la session, vous donne une identité cohérente à vérifier au lieu d'une clé par appareil.
- Authentification de l'utilisateur. L'utilisateur prouve qui il est avec une clé SSH (préférée) ou un mot de passe (plus faible, hameçonnable, souvent partagé). Sur le matériel OT, c'est fréquemment un unique identifiant partagé inscrit dans un runbook.
- Canal chiffré. Négocié automatiquement. Cette partie est déjà solide, c'est pourquoi le travail de sécurité SSH porte sur les deux premiers points, pas sur le chiffrement.
À retenir : SSH n'a pas besoin d'aide pour chiffrer. Il a besoin d'aide sur qui peut atteindre le port et qui détient l'identifiant. Les deux modèles d'accès ci-dessous se distinguent précisément sur cette seconde question.
Deux façons de médier le SSH (choisissez-en une)
Modèle A : autorisation par chemin réseau
Le modèle d'enclave standard en refus par défaut. Vous écrivez une règle allow pour le protocole ssh (port 22) d'un principal vers l'actif, et l'opérateur se connecte avec son propre client SSH et sa propre clé. La gate applique l'identité et la politique et journalise la session, mais l'identifiant SSH reste entre l'opérateur et l'appareil.
- Ajoutez l'appareil en tant qu'actif et placez-le dans une enclave, voir Protéger un actif avec les enclaves.
- Ajoutez une règle
allowpourssh(outcp:{custom_port}si SSH ne tourne pas sur le 22), limitée à l'utilisateur, au groupe ou à l'actif pair qui doit se connecter. - L'opérateur exécute
ssh user@<overlay-name-or-ip>. Rien ne change sur l'appareil.
Utilisez le Modèle A lorsque les opérateurs sont de confiance pour gérer leurs propres clés, lorsqu'un flux machine à machine a besoin de SSH (un hôte d'automatisation atteignant un contrôleur), ou lorsque vous voulez le chemin le plus léger qui offre tout de même le refus par défaut et la journalisation. La limite : l'identifiant de l'appareil est toujours dans la nature, donc révoquer l'accès signifie révoquer l'autorisation et, à terme, faire tourner la clé.
Modèle B : proxy d'accès à distance
Lorsque l'identifiant de l'appareil ne doit jamais quitter la gate, utilisez l'accès à distance : la gate stocke la clé SSH ou le mot de passe, l'injecte à la connexion, et sert la session dans un onglet de navigateur. L'opérateur s'authentifie en son nom propre et ne détient jamais l'identifiant de l'appareil.
1. Créer l'actif et son service SSH
Ajoutez l'appareil en tant qu'actif et déclarez son service SSH:22. Ouvrez l'actif, cliquez sur Edit Network, et saisissez les informations du service d'accès à distance (les identifiants qu'Access Gate utilise à la connexion).
2. Créer une enclave
Créez une enclave contenant l'actif et l'utilisateur ou le groupe auquel vous voulez accorder l'accès.
3. Activer l'accès à distance sur l'autorisation
Pour accorder l'accès à distance, une session proxy maintenue par Access Gate, sélectionnez l'option Remote Access. Avec cette option, les identifiants stockés sur l'Access Gate sont utilisés à la connexion, sans être exposés à l'utilisateur final. Accordez ensuite l'accès.
Côté utilisateur
L'utilisateur s'authentifie via un écran d'accès et voit les sessions d'accès à distance qu'il peut activer.
Cliquer sur le lien ouvre une session de navigateur avec accès à distance vers la machine cible.
Les identifiants ne vivent pas sur la machine de l'opérateur. L'autorisation (creds=...) est injectée côté serveur, de sorte que la personne au clavier ne détient jamais la clé SSH ni le mot de passe du boîtier MOXA. Révoquer l'accès, c'est révoquer une autorisation, pas faire tourner un identifiant d'appareil. Pour le modèle plus large de session d'administration (RDP, VNC, enregistrement de session), voir Gestion des accès à privilèges.
Notes de durcissement
- Préférez les clés aux mots de passe, et sur l'appareil désactivez l'authentification par mot de passe une fois l'accès par clé éprouvé. Avec le Modèle B, cela importe peu pour l'opérateur, la gate détient l'identifiant.
- SFTP et SCP empruntent la même autorisation. Le transfert de fichiers est du SSH, donc la même règle qui accorde le shell régit aussi le mouvement de fichiers. Délimitez-la délibérément si un opérateur doit obtenir un shell mais pas la copie de fichiers en masse.
- La révocation diffère selon le modèle. La révocation du Modèle A est immédiate au niveau réseau, mais la clé de l'appareil subsiste jusqu'à sa rotation. La révocation du Modèle B supprime en une seule étape l'unique chemin vers l'identifiant.
Récapitulatif
Vous avez deux façons de médier le SSH : une autorisation par chemin réseau (Modèle A) où l'opérateur détient sa propre clé et où la gate applique la joignabilité et la journalisation, ou un proxy d'accès à distance (Modèle B) où la gate détient l'identifiant et sert une session par navigateur afin que l'opérateur ne touche jamais la clé de l'appareil. Les deux reposent sur des enclaves en refus par défaut, et aucun n'exige de modifier l'appareil.
Optez pour le Modèle A lorsque les opérateurs gèrent leurs propres clés ou pour du SSH machine à machine ; optez pour le Modèle B lorsqu'un identifiant partagé ou non rotable ne doit jamais quitter la gate.