|
Après avoir activé un serveur SSH, vous pouvez envisager de retirer les serveurs qui fournissaient auparavant des services désormais accessibles via SSH. Cela dépend fortement de votre infrastructure et de vos politiques de sécurité. Voici quelques exemples :
* Serveurs uniquement pour l'administration à distance : Si vous utilisiez auparavant RDP (Remote Desktop Protocol), VNC ou d'autres méthodes d'accès à distance uniquement pour des tâches administratives, ces serveurs pourraient être retirés *si* SSH offre des fonctionnalités et une sécurité équivalentes. C'est le scénario le plus courant.
* Serveurs de saut (avec limitations) : Si vous disposiez d'un serveur de saut qui facilitait uniquement l'accès à d'autres serveurs internes et que SSH permet désormais un accès direct et sécurisé à ces cibles (avec des contrôles d'accès appropriés), le serveur de saut *pourrait* être un candidat à la retraite. Cependant, cela nécessite un examen attentif des meilleures pratiques de sécurité et de la segmentation du réseau. Un serveur de saut fournit souvent une couche de sécurité et d'audit qui peut être difficile à remplacer entièrement.
* Serveurs hébergeant des applications existantes accessibles uniquement via des méthodes non sécurisées : Si vous avez des applications exécutées sur des serveurs plus anciens accessibles uniquement via des protocoles non sécurisés (comme telnet), remplacer cet accès par SSH à un serveur plus sécurisé hébergeant la même application vous permettrait de mettre hors service le système non sécurisé.
* Serveurs utilisés pour des tâches automatisées accessibles via des protocoles non sécurisés : De la même manière que ci-dessus, si les tâches automatisées reposaient auparavant sur des méthodes de connexion non sécurisées, la migration vers SSH pour une automatisation sécurisée pourrait rendre les anciens serveurs redondants.
Considérations importantes avant la retraite :
* Sécurité : Assurez-vous que votre serveur SSH est correctement sécurisé (mots de passe/clés forts, règles de pare-feu, etc.) avant de retirer tout autre serveur.
* Redondance : Ne retirez pas un serveur avant d'avoir vérifié que le remplacement (votre serveur SSH) est entièrement fonctionnel et stable.
* Migration des données : Si le serveur contient des données, vous aurez besoin d'un plan pour migrer ces données avant la mise hors service.
* Compatibilité des applications : Assurez-vous que toutes les applications et services peuvent fonctionner correctement avec le nouvel accès basé sur SSH.
* Audit et journalisation : Votre serveur SSH a besoin d'une journalisation robuste pour maintenir la sécurité et la conformité.
En bref, SSH peut consolider l'accès à divers systèmes, mais le déclassement nécessite une planification et une évaluation des risques approfondies. La simple activation de SSH ne rend pas automatiquement les autres serveurs obsolètes.
|
