Utiliser une liste de sécurité VPS récurrente, pas un durcissement unique
Le durcissement initial n’est que le premier contrôle. Un VPS sûr exige tout au long de sa vie un inventaire à jour, des accès attribuables, des logiciels pris en charge, des correctifs planifiés, une exposition limitée, une détection utile, une procédure d’incident, des sauvegardes indépendantes et des restaurations répétées.
Points clés
- Rythme de révision
- Après un changement, une alerte et selon un calendrier documenté
- Base des accès
- Comptes individuels, clés SSH, privilèges limités, récupération protégée
- Base des correctifs
- Logiciels pris en charge, mises à jour de sécurité et redémarrages vérifiés
- Preuve de reprise
- Une restauration réussie, pas seulement l’existence d’une tâche de sauvegarde
Maintenir un inventaire actuel et des responsables nommés
Consignez finalité du VPS, région, version système, sources de paquets, applications, domaines, certificats, adresses publiques, services en écoute, administrateurs, identités d’automatisation, secrets, sauvegardes, supervision et dépendances. Nommez un responsable et une date de revue. Un logiciel inconnu ou un compte oublié ne peut être corrigé ou supprimé fiablement.
Comparez l’inventaire prévu avec la réalité après les déploiements. Des commandes comme ss -lntup révèlent les services en écoute ; inventaires des paquets et processus expliquent l’exécution. Protégez ces sorties car elles décrivent la surface d’attaque. Supprimez images, dépôts, exemples, comptes, clés et DNS obsolètes.
- Documentez pourquoi chaque port public est nécessaire.
- Suivez l’expiration des certificats et domaines hors du serveur.
- Revoyez l’inventaire après chaque changement applicatif important.
Rendre l’accès administratif limité et récupérable
Donnez à chaque administrateur un compte individuel et une clé SSH protégée. Accordez uniquement les privilèges requis et retirez rapidement les accès. Examinez /etc/ssh/sshd_config, validez avant rechargement et gardez une seconde session testée ou la console afin qu’une erreur ne bloque pas toute reprise.
Protégez le compte d’hébergement par un mot de passe unique et l’authentification multifacteur si disponible. Stockez procédures d’urgence et codes de récupération dans un lieu contrôlé hors du VPS. Limitation de débit et supervision réduisent les attaques répétées, sans remplacer clés solides, logiciels actuels et surface exposée minimale.
- Ne désactivez ou limitez root qu’après validation d’une autre voie privilégiée.
- Faites tourner les identifiants après changement d’équipe ou suspicion d’exposition.
- Ne placez jamais clés privées ou codes de récupération dans les tickets.
Corriger les composants pris en charge et vérifier le résultat
Utilisez une version système prise en charge et des dépôts fiables. Surveillez les avis de sécurité, planifiez selon exposition et gravité et testez les changements critiques. Une mise à jour n’est terminée qu’après redémarrage des services ou du noyau requis et contrôle élémentaire de l’application.
Incluez runtimes, conteneurs, panneaux, extensions, bibliothèques, moteurs de base et applications personnalisées dans l’inventaire. Les mises à jour automatiques raccourcissent l’exposition, mais définissez la détection des échecs et redémarrages. Retirez les logiciels sans correctifs plutôt que de compenser indéfiniment par le pare-feu.
- Créez un point de reprise avant les changements risqués sans en faire l’unique sauvegarde.
- Vérifiez signatures des paquets et propriétaire des dépôts.
- Consignez chaque exception avec responsable et date d’expiration.
Collecter des signaux exploitables et préparer la réponse
Surveillez disponibilité, échecs d’authentification, changements de privilèges, ports inattendus, épuisement disque, échecs de sauvegarde, trafic sortant inhabituel et événements applicatifs. Utilisez journalctl et les journaux pertinents pendant l’enquête, mais ne collectez que ce qui sert une finalité déclarée et protégez les journaux contre accès ou modification non autorisés.
Rédigez une procédure compacte : décision de confinement, accès console, conservation des preuves, rotation des identifiants, reconstruction propre et communication aux utilisateurs ou fournisseurs. Lors d’une compromission présumée, préservez les preuves pertinentes avant le nettoyage destructeur lorsque cela est sûr et légal.
- Synchronisez l’heure et utilisez des fuseaux explicites.
- Envoyez les alertes critiques hors du VPS affecté.
- Exercez un scénario de compromission de compte ou panne de service.
Tester la reprise et boucler la revue
Gardez des sauvegardes chiffrées et versionnées hors du domaine de panne principal. Testez une restauration complète isolée, incluant bases, permissions, secrets, certificats et santé applicative. Mesurez âge des données récupérables et durée totale face aux objectifs de la charge.
Exécutez cette liste après tout changement important et selon un rythme proportionné au risque. Consignez constats, responsables, échéances et clôture vérifiée. Au retrait, exportez les éléments requis, révoquez clés et jetons, supprimez DNS et automatisations, effacez les données via le processus disponible et confirmez que la supervision n’attend plus ce serveur.
- Gardez les instructions de restauration disponibles sans le panneau.
- Examinez accès, correctifs, exposition, alertes et reprise comme un ensemble.
- Transformez tout incident et échec de restauration en amélioration suivie.
Sources
Questions fréquentes
À quelle fréquence revoir la sécurité d’un VPS ?
Après les changements ou alertes importants et selon un calendrier récurrent documenté. Les systèmes exposés et charges sensibles exigent généralement des contrôles plus fréquents que des serveurs temporaires peu risqués.
Changer le port SSH est-il un contrôle de sécurité ?
Cela peut réduire le bruit des scans, mais ne remplace pas clés robustes, logiciels actuels, accès limités, règles de pare-feu, supervision et récupération protégée.
Faut-il activer les mises à jour automatiques de sécurité ?
Elles raccourcissent l’exposition, mais définissez mises à jour permises, maintenance, redémarrages, alertes d’échec et contrôles applicatifs. Les systèmes critiques peuvent aussi nécessiter des tests progressifs.
Quel est le test minimal d’une sauvegarde ?
Restaurez données et configuration requises dans un environnement isolé, démarrez l’application, vérifiez cohérence et accès, mesurez le résultat et documentez toute dépendance manquante.