Commencez par un accès vérifié et une voie de récupération, puis configurez une administration individuelle, des clés SSH testées, un pare-feu restrictif, des logiciels maintenus et des sauvegardes indépendantes. Appliquez les changements progressivement et vérifiez une nouvelle session avant de fermer l'ancienne.
Établissez un point de départ fiable
Avant de modifier la machine, confirmez le système d'exploitation attendu, la méthode d'accès et la voie de récupération. Vérifiez l'identité de l'hôte SSH à l'aide des informations approuvées par l'opérateur plutôt que d'accepter une clé inattendue sans enquête. Gardez les identifiants temporaires privés et remplacez-les selon le processus prévu. Notez quelle personne est responsable de la maintenance et quelles options de récupération sont réellement disponibles pour ce service.
Gardez une session d'administration fonctionnelle ouverte pendant les modifications d'accès. Une recette de durcissement copiée peut supprimer le seul identifiant utilisable lorsqu'elle suppose une distribution ou une organisation de comptes différente. Effectuez un changement à la fois, vérifiez son résultat effectif et conservez une voie de retour. L'objectif est un système que vous pouvez maintenir en toute sécurité, et non une configuration qui semble stricte mais ne peut pas être administrée.
Rendez l'accès à SSH délibéré
Créez un accès administratif individuel avec les privilèges appropriés plutôt que de partager un identifiant root permanent. Installez et testez la clé publique prévue, en conservant la clé privée sur le point de terminaison autorisé. La documentation OpenSSH de Ubuntu explique la configuration du serveur et les choix d'authentification. Lisez la configuration effective de votre distribution, y compris les fichiers inclus, avant de supposer que la modification d'un paramètre a changé l'ensemble du service.
Testez l'accès par clé via une seconde session avant de modifier l'authentification par mot de passe ou les règles de connexion privilégiée. Assurez-vous que le nouveau compte peut effectuer l'administration nécessaire. Examinez toute automatisation qui dépend de la méthode précédente et remplacez son accès de manière délibérée. Une clé est un identifiant d'accès : utilisez un emplacement de stockage privé et un processus de rotation plutôt que de laisser des copies dans les répertoires d'application.
Exposez l'application, pas la machine entière
Inventoriez les services en écoute et identifiez ceux qui doivent être publics. Une application web peut avoir besoin de HTTP et HTTPS, tandis que sa base de données peut rester accessible uniquement via le chemin interne prévu. Ubuntu documente UFW comme outil de configuration de pare-feu, mais la politique utile est indépendante de l'outil : autorisez le trafic requis et restreignez l'administration aux sources approuvées lorsque c'est possible.
Vérifiez les contrôles au niveau de l'hôte et du fournisseur si le service les inclut. Avant d'activer un ensemble de règles restrictives, autorisez le chemin d'administration testé et vérifiez l'accès depuis une autre session. Ne supposez pas que le déplacement de SSH vers un autre port remplace l'authentification ou les correctifs. Gardez les règles de pare-feu compréhensibles afin que le dépannage futur ne conduise pas à ouvrir tous les ports comme solution de contournement.
| Changement | Vérifier avant d'appliquer | Vérifier après |
|---|---|---|
| Nouvelle clé SSH | Compte et clé publique corrects | La seconde session authentifiée par clé fonctionne |
| Pare-feu restrictif | Chemins de service et de récupération requis | L'application publique fonctionne ; les ports non prévus sont fermés |
| Mise à jour logicielle | Implications pour la sauvegarde et le redémarrage | Les services redémarrent et les tests d'application réussissent |
| Modification des permissions de service | Chemins de lecture et d'écriture requis | L'application fonctionne sans accès système élargi |
Planifiez les mises à jour comme un processus d'exploitation
Maintenez le système et les dépendances applicatives. Les recommandations de mise à jour automatique de Ubuntu décrivent les mises à niveau sans intervention, les origines autorisées et le comportement de redémarrage. Un dépôt tiers n'est pas automatiquement couvert du seul fait qu'il a été ajouté à la machine. Examinez ce que le processus de mise à jour configuré inclut réellement, et donnez aux applications installées séparément leur propre voie de maintenance.
Décidez comment les redémarrages de service et les redémarrages système seront gérés. L'application d'une mise à jour de paquet ne signifie pas toujours que chaque processus en cours utilise le nouveau code. Utilisez une fenêtre de maintenance lorsque la charge de travail l'exige, et effectuez une vérification simple de l'application ensuite. Si un paquet nécessite des étapes de migration manuelles, documentez-les au lieu de désactiver toutes les mises à jour indéfiniment et d'oublier l'exposition qui en résulte.
Restreignez l'accès aux applications et protégez la récupération
Exécutez les services avec les permissions dont ils ont besoin, et séparez le contenu public des secrets et des métadonnées de déploiement. Un processus web ne doit pas pouvoir réécrire tous les paramètres système. Gardez les secrets d'environnement en dehors des répertoires servis publiquement et évitez de les inclure dans les journaux, les exports de support ou les sauvegardes générales sans politique de protection intentionnelle. Supprimez les paquets et services inutilisés lorsqu'ils n'ont aucune utilité opérationnelle.
Maintenez une sauvegarde indépendante et testez la restauration de l'application dans un environnement isolé. Restreignez les identifiants de sauvegarde afin qu'une application compromise ne puisse pas supprimer automatiquement toutes les copies de récupération. Surveillez la capacité disque, l'âge des sauvegardes et les défaillances de service. La journalisation doit répondre à des questions opérationnelles définies, avec un accès et une rétention contrôlés ; elle ne doit pas devenir une copie illimitée de requêtes sensibles.
Une séquence de premier déploiement qui reste vérifiable
Pour un nouveau VPS, vérifiez d'abord l'accès et la récupération, puis établissez le compte administratif et la clé testée. Configurez le pare-feu, appliquez les mises à jour et déployez l'application sous son compte de service prévu. Confirmez le comportement public depuis un autre environnement, vérifiez que les fichiers privés ne peuvent pas être récupérés et effectuez une restauration de sauvegarde. Consignez chaque décision et la voie de retour pour annuler une modification d'accès.
Vector VPS, Pulse NVMe et certains plans dédiés sélectionnés présentent des choix Linux dans le catalogue SwissOctet. Confirmez l'image choisie et la répartition des tâches de maintenance avant de commander. Aucun nom d'image Linux ne prouve que le durcissement, les mises à jour ou les sauvegardes sont déjà gérés. La base de référence est l'ensemble des contrôles que vous configurez, vérifiez et continuez à maintenir à mesure que le projet évolue.
Votre liste de contrôle pratique.
- Vérifiez l'identité de l'hôte SSH et la voie de récupération.
- Testez l'accès par clé individuelle dans une seconde session.
- Restreignez les services en écoute et les règles de pare-feu.
- Examinez la couverture des mises à jour et le comportement de redémarrage.
- Séparez les secrets des fichiers publics et des permissions de service.
- Testez une copie de récupération indépendante.
Les détails qui comptent.
Dois-je désactiver immédiatement la connexion par mot de passe ?+
Établissez et testez d'abord l'accès par clé de remplacement et la voie de récupération. Modifiez ensuite l'authentification selon votre configuration prise en charge.
Un changement de port SSH remplace-t-il le durcissement ?+
Non. Il ne remplace pas une authentification forte, un accès restreint, les mises à jour ou des privilèges de compte appropriés.
Les mises à jour automatiques suffisent-elles pour chaque application ?+
Non. Vérifiez les dépôts autorisés, les exigences de redémarrage et les logiciels installés en dehors du processus de mise à jour du système.
Allez à la source.
Ces références soutiennent les concepts techniques de ce guide. Suivez la documentation actuelle avant de modifier un système de production.
- Serveur Ubuntu : serveur OpenSSH ubuntu.com
- Serveur Ubuntu : pare-feu ubuntu.com
- Serveur Ubuntu : mises à jour automatiques ubuntu.com
Conseils éditoriaux par SwissOctet. Les exemples sont illustratifs. Les spécifications de service, les options disponibles et les conditions contractuelles doivent être vérifiées séparément.