Un cabinet d'ingénierie de Ferney-Voltaire nous contacte parce que son responsable informatique, seul à connaître l'infrastructure, quitte l'entreprise à la fin du mois. Deux serveurs Debian font tourner l'hyperviseur, un relais de messagerie, un serveur mandataire qui publie l'application interne, et une pile de conteneurs installée trois ans plus tôt. Aucune documentation n'existe. Les connexions se font avec un compte root dont le mot de passe est connu d'une seule personne. Les dernières mises à jour datent d'une période que personne ne sait situer.
Linux sur un serveur n'est ni un choix militant ni un loisir de spécialiste. C'est le système sur lequel tournent la plupart des hyperviseurs, des serveurs web, des relais de courrier et des applications livrées par un prestataire. Il coûte moins cher en droits d'utilisation, il consomme moins de ressources, et il se pilote très bien à distance. En contrepartie, il déplace l'exigence: il ne vous demande pas d'argent de licence, il vous demande de savoir qui applique les correctifs, qui détient les accès et qui saura le remettre en service. Nous exploitons ces machines dans la gestion des serveurs.
Les rôles où Linux s'impose naturellement dans une PME
Le premier est l'hôte de virtualisation. Proxmox VE repose sur une base Debian, et le serveur qui porte vos machines virtuelles est donc déjà un serveur Linux, même si personne ne le formule ainsi. Les critères de choix entre hyperviseurs sont détaillés dans Proxmox, ESXi ou Hyper-V.
Le deuxième regroupe les services d'infrastructure réseau: un pare-feu, un point de terminaison de tunnel privé, un relais de messagerie qui filtre le courrier sortant, un serveur mandataire inverse qui publie une application interne en HTTPS. Ces fonctions demandent peu de ressources et se documentent entièrement dans des fichiers de configuration, ce qui les rend faciles à reproduire à l'identique.
Le troisième correspond aux applications que nous livrons: un site, une interface interne, une base de données applicative, une pile de conteneurs. La virtualisation applicative par conteneurs se traite très bien sans orchestrateur complexe, question que nous développons dans Docker sans Kubernetes.
Linux ne remplace pas tout. Une base SQL Server et l'application de gestion qui s'y accroche restent sur Windows Server, et c'est un partage de rôles parfaitement tenable. Une PME de trente personnes fait couramment cohabiter les deux systèmes, avec une seule supervision et un seul prestataire.
SSH est la porte d'entrée, et elle se ferme comme une autre
L'équivalent Linux du bureau à distance s'appelle SSH. Le raisonnement est identique à celui que nous tenons dans bureau à distance ouvert sur Internet: un service d'administration publié sur Internet est balayé en permanence par des robots qui essaient des combinaisons de comptes et de mots de passe.
Quatre réglages suffisent à changer la situation, et nous les appliquons systématiquement.
- L'authentification par mot de passe est désactivée au profit de clés cryptographiques nominatives, une par personne, révocables individuellement le jour d'un départ.
- La connexion directe au compte
rootest interdite. Chacun se connecte avec son propre compte, puis élève ses droits viasudo, ce qui laisse une trace exploitable dans les journaux. - Le service d'administration n'est joignable que depuis le réseau interne ou par un tunnel privé d'entreprise, et jamais publié directement sur Internet.
- Les clés privées ne circulent pas par messagerie et ne dorment pas dans un dossier partagé. Les secrets d'infrastructure vivent dans un coffre d'équipe, avec des droits par personne et une trace des consultations.
Cette dernière règle a une conséquence directe le jour où un administrateur quitte l'entreprise: vous supprimez sa clé publique sur les serveurs concernés et l'accès disparaît immédiatement, sans avoir à changer un secret partagé sur l'ensemble des machines, opération que personne ne mène jamais jusqu'au bout dans l'urgence d'un départ.
Les mises à jour ne se font pas toutes seules, même sur Linux
Une idée tenace veut qu'un serveur Linux se maintienne seul. Dans les faits, un serveur laissé plusieurs années sans intervention accumule trois problèmes distincts.
Les correctifs de sécurité ne sont pas appliqués. Ils existent pourtant, publiés régulièrement par la distribution, et concernent souvent des composants exposés comme le serveur web ou la bibliothèque de chiffrement. Nous activons les mises à jour de sécurité automatiques sur les paquets sans risque, et nous planifions les autres dans une fenêtre convenue.
La version de la distribution sort de sa période de maintenance. Chaque éditeur publie un calendrier de support par version, avec une date à partir de laquelle plus aucun correctif n'est produit. Nous vérifions ce calendrier officiel pour votre version précise plutôt que de nous fier à une estimation, car franchir cette date sans le savoir revient à exploiter un système définitivement figé. Une montée de version majeure se prépare, se teste sur une copie, et s'exécute dans une fenêtre planifiée, pas en urgence un vendredi.
Le disque se remplit, presque toujours par les journaux ou par des images de conteneurs qui s'accumulent. Le serveur cesse alors d'écrire, les services s'arrêtent en cascade, et le diagnostic prend plus de temps que la panne elle-même. Une rotation des journaux et une sonde sur le taux de remplissage évitent ce scénario, comme nous le décrivons dans voir le disque plein avant le lundi.
Le vrai risque d'un serveur Linux en PME est la dépendance à une seule personne
Le problème le plus fréquent que nous reprenons n'est pas technique. Une pile applicative a été montée par un stagiaire compétent ou par un développeur de passage, elle fonctionne très bien, et plus personne ne sait comment elle démarre. Les fichiers de configuration ne sont pas dans un dépôt, les mots de passe sont dans des variables d'environnement écrites à la main, et la procédure de redémarrage se transmet oralement.
Nous traitons ce risque en trois gestes. Nous rassemblons la configuration de chaque service dans un dépôt versionné, ce qui rend l'installation reproductible et permet de comparer deux états. Nous écrivons une fiche par serveur, indiquant son rôle, ses dépendances, la procédure d'arrêt et de redémarrage dans l'ordre, et l'emplacement de ses sauvegardes. Nous automatisons enfin ce qui se répète, afin qu'une réinstallation ne dépende plus de la mémoire d'une personne, sujet développé dans écrire l'infrastructure plutôt que la cliquer.
Un mot sur les sauvegardes, car le sujet se pose différemment de celui des postes de travail. Sauvegarder les données applicatives ne suffit pas: sans la configuration des services, vous restaurez des fichiers sans savoir quoi en faire. Et une copie déposée sur le même disque ou sur un boîtier de stockage posé dans le même local ne protège ni du chiffrement par rançongiciel ni de l'incendie, raisonnement que nous détaillons dans la règle 3-2-1.
Notre méthode pour reprendre un parc Linux existant
Nous commençons par un inventaire écrit: pour chaque machine, la distribution et sa version, les services qui tournent réellement, les ports ouverts, les comptes disposant de droits élevés, et la destination des sauvegardes. Nous coupons ensuite ce qui est exposé sans raison, nous remplaçons les accès partagés par des clés nominatives, et nous appliquons la première salve de correctifs après avoir vérifié que les services redémarrent proprement.
Nous posons la supervision dans la foulée, avec des sondes sur le remplissage des disques, la mémoire, la disponibilité des services et l'expiration des certificats. Nous documentons, et nous laissons à la direction un document lisible sans compétence technique, qui répond à une question simple: si cette machine s'arrête, qui appeler et quel service est interrompu.
Cette exploitation entre dans notre contrat d'infogérance à partir de 120 HT / mois, qui couvre les correctifs, la supervision, la vérification des sauvegardes et le support. En dehors d'un contrat, une intervention d'urgence se facture 230 HT / h. Nous nous déplaçons dans le Bassin Genevois pour le matériel et intervenons à distance ensuite, avec le même montant hors taxes en euros et en francs.
Si la seule personne qui connaît vos serveurs Linux part bientôt, ou si vous ne savez pas quels services tournent dans votre local technique, prenons rendez-vous avant son départ. Reprendre une machine documentée par son administrateur demande quelques heures. La reconstituer après coup demande beaucoup plus.