Sudoer Linux : bien plus qu’un simple accès administrateur
Un sudoer, c’est un utilisateur autorisé à exécuter des commandes avec les privilèges d’un autre compte — généralement root — via la commande sudo. Configurer correctement les droits sudo est l’une des premières décisions techniques qu’une petite structure doit prendre le jour où elle installe son premier serveur Linux. Et c’est précisément là que j’ai vu le plus de dégâts, souvent silencieux, chez mes clients PME.
Je me souviens d’un client bourguignon en 2011, une petite imprimerie qui venait de migrer son serveur de fichiers de Windows Server vers un Debian pour économiser sur les licences. Le prestataire qui avait fait l’installation initiale avait donné les pleins droits sudo à tous les employés « pour ne pas être dérangé le week-end ». Six mois plus tard, un stagiaire a lancé une commande de nettoyage de disque un peu trop large, croyant travailler sur son répertoire personnel. Résultat : deux jours de restauration à partir d’une sauvegarde vieille d’une semaine. La tech n’était pas en cause — la gouvernance des accès, si.
Comprendre le fichier sudoers
Le cœur du système repose sur le fichier /etc/sudoers, qui définit qui peut faire quoi, et en tant que qui. Ce fichier ne doit jamais être édité directement avec un éditeur classique. La bonne pratique, depuis les débuts de sudo dans les distributions que j’ai connues au fil des migrations, est d’utiliser la commande dédiée :
sudo visudo
Cette commande verrouille le fichier pendant l’édition et, surtout, vérifie la syntaxe avant d’enregistrer. C’est un détail qui semble mineur, mais qui évite l’erreur la plus dangereuse de toutes : casser /etc/sudoers au point de ne plus pouvoir utiliser sudo du tout, y compris pour corriger l’erreur elle-même.
La structure d’une règle sudoers
Une ligne type dans le fichier ressemble à ceci :
marie ALL=(ALL:ALL) ALL
Cela signifie que l’utilisateur « marie » peut, depuis n’importe quelle machine (premier ALL), exécuter des commandes en tant que n’importe quel utilisateur et groupe (ALL:ALL), pour n’importe quelle commande (dernier ALL). C’est la configuration la plus large possible, et c’est précisément celle que je déconseille pour une PME de moins de vingt postes. Sur ce type de structure, on n’a presque jamais besoin d’un accès aussi ouvert au quotidien.
Une approche plus pragmatique, celle que je recommandais systématiquement lors de mes missions de conseil entre 2004 et 2017, consiste à limiter les droits aux commandes réellement nécessaires :
marie ALL=(ALL) /usr/bin/systemctl restart apache2, /usr/bin/systemctl restart mysql
Avec cette ligne, Marie peut redémarrer le serveur web et la base de données sans avoir un accès root complet. Si son compte est compromis un jour — par un mot de passe faible ou un poste infecté — l’attaquant hérite d’un périmètre limité, pas des clés de tout le système.
Le groupe sudo : la méthode la plus courante
Sur Debian et Ubuntu, la méthode la plus répandue consiste à ajouter un utilisateur au groupe sudo plutôt que d’écrire une ligne individuelle :
sudo usermod -aG sudo nom_utilisateur
Cette approche fonctionne bien tant que le groupe sudo reste réservé aux personnes qui en ont réellement besoin — l’administrateur système ou, dans une petite structure, le dirigeant technique et éventuellement un suppléant. Le piège classique que j’ai observé chez au moins une dizaine de clients : au fil des années, on ajoute des comptes au groupe sudo pour « dépanner rapidement », et personne ne fait jamais le ménage. Cinq ans plus tard, huit personnes ont des accès root sur un serveur qui héberge la comptabilité de l’entreprise, et plus personne ne sait pourquoi la moitié d’entre elles en ont besoin.
Mise en garde : les erreurs de configuration sudoers les plus dangereuses
Attention à une pratique que je continue de voir, y compris chez des développeurs par ailleurs compétents : accorder NOPASSWD sur une règle trop large, comme dans cet exemple à proscrire :
marie ALL=(ALL) NOPASSWD: ALL
Cette ligne permet à Marie d’exécuter absolument n’importe quelle commande en root, sans jamais retaper son mot de passe. C’est confortable pour des scripts automatisés bien précis — je l’utilise moi-même pour une tâche cron spécifique de sauvegarde chez un client, mais jamais pour un accès interactif complet. Le risque : si le poste de Marie reste déverrouillé cinq minutes à la machine à café, n’importe qui peut agir en root sans aucune barrière. Sur un serveur de production, cette combinaison NOPASSWD + ALL est à mes yeux la configuration sudoers la plus risquée qui soit, et pourtant l’une des plus fréquentes, précisément parce qu’elle règle un inconfort à court terme.
Deuxième piège fréquent : accorder sudo sur un éditeur de texte générique comme vim ou nano. Cela semble anodin, mais n’importe qui sachant utiliser l’éditeur peut ensuite ouvrir un shell depuis l’intérieur (une fonctionnalité native de la plupart des éditeurs) et se retrouver avec un accès root complet, largement au-delà de ce que la règle voulait accorder. Je le vérifie systématiquement lors de mes audits : donner sudo sur un éditeur, c’est donner sudo sur tout.
Vérifier ses droits avant d’agir
Avant toute intervention sur un serveur qui n’est pas le vôtre au quotidien, la commande suivante permet de lister précisément ce qu’un compte est autorisé à faire :
sudo -l
J’insiste toujours auprès des dirigeants de PME que j’accompagne : cette commande devrait faire partie de la checklist d’arrivée de tout nouveau technicien ou prestataire externe. On vérifie les droits accordés, on les compare à ce qui est réellement nécessaire pour la mission, et on ajuste. C’est une habitude qui prend trente secondes et qui évite des situations bien plus coûteuses à corriger après coup.
Sudo ou compte root direct : quel choix pour une petite structure
Une question que l’on me pose souvent : pourquoi ne pas simplement activer le compte root et s’y connecter directement, plutôt que de jongler avec sudo ? La réponse tient en un mot : la traçabilité. Chaque commande passée via sudo est journalisée, avec l’identité de l’utilisateur qui l’a exécutée, dans /var/log/auth.log sur les distributions Debian et dérivées. Avec un accès root partagé, en revanche, impossible de savoir qui a fait quoi en cas d’incident — et pour une PME qui doit un jour justifier ses pratiques auprès d’un assureur ou d’un client exigeant sur la sécurité, ce journal d’audit a une vraie valeur. Ce n’est pas une question de confiance envers l’équipe ; c’est une question de pouvoir reconstituer les faits le jour où quelque chose tourne mal.
À retenir
Configurer sudoers correctement n’a rien de spectaculaire, et c’est justement pour cela qu’on le néglige. Trois principes suffisent pour la grande majorité des petites structures : limiter les droits aux commandes réellement nécessaires plutôt qu’accorder ALL par réflexe, faire un ménage annuel du groupe sudo pour retirer les accès obsolètes, et bannir la combinaison NOPASSWD + ALL sauf cas d’automatisation très précis et documenté. Trente ans plus tard, je remarque que les entreprises qui évitent les incidents sérieux ne sont pas celles qui ont les outils les plus sophistiqués, mais celles qui appliquent ces quelques règles de bon sens avec constance. Posez-vous la question, sur votre propre serveur : si je devais lister aujourd’hui qui a un accès root et pourquoi, saurais-je répondre en moins d’une minute ?
Pour aller plus loin
Ingénieur logiciel retraité devenu consultant en architecture numérique
Trente ans d'infrastructure informatique au service des PME.