Niveau 🟡 intermédiaire
Durée estimée : 15 min · Prérequis : Durcissement SSH
NOPASSWD, déjà vu en M1Le moindre privilège, c'est donner à chaque personne exactement les clés dont elle a besoin, ni
plus ni moins — pas un trousseau maître « au cas où ». Moins il y a de clés maîtresses en
circulation, moins une clé perdue ou volée a de conséquences graves.
Le principe du moindre privilège (principle of least privilege) énonce qu'un utilisateur,
un processus, ou un service ne devrait disposer que des droits strictement nécessaires à sa
tâche — jamais plus, « par confort » ou « au cas où ». Chaque droit accordé en excès est une
surface d'attaque supplémentaire, qui n'apporte aucun bénéfice tant que tout se passe bien, mais
aggrave les conséquences dès qu'un incident survient.
L'exemple déjà traité dans ce wiki : NOPASSWD. M1
a détaillé pourquoi configurer sudo sans mot de passe (NOPASSWD) est déconseillé : cela
transforme la simple possession d'un compte (ou d'une clé SSH, vue en
M1) en accès root immédiat, sans étape de confirmation. Vu
sous l'angle du moindre privilège, NOPASSWD accorde un privilège permanent (l'accès root sans
confirmation) là où une confirmation ponctuelle, à chaque usage, suffirait largement — un excès
de droit qui n'apporte, au quotidien, qu'un gain de confort marginal.
Ce même principe se retrouve ailleurs dans ce wiki, une fois qu'on sait le reconnaître :
127.0.0.1 uniquement plutôt que sur toutes les interfacesUID/GID adaptés plutôt qu'un root interne au conteneurReconnaître ce principe permet de généraliser une bonne pratique déjà appliquée
ponctuellement (le refus de NOPASSWD) à toute nouvelle décision de configuration : à chaque
fois qu'un choix accorde un droit, une question se pose — ce droit est-il strictement
nécessaire à la tâche, ou juste plus simple à configurer sur le moment ?
🧪 Concrètement, sur notre exemple : le refus de
NOPASSWD, déjà détaillé en M1, reste
l'application la plus directe de ce principe sur notre installation — chaquesudocontinue
d'exiger une confirmation par mot de passe, en session interactive, sans exception.
Le même outil (sudo), configuré différemment, change radicalement la conséquence d'une seule
clé compromise — la différence tient entièrement dans le respect ou non du moindre privilège.
sudo cat /etc/sudoers | grep -i nopasswd
# Ne doit rien retourner -- déjà vu en M1, la vérification centrale
# de cette page
# Repérer, plus largement, tout privilège accordé sans nécessité :
groups
# Liste tes propres groupes -- chacun devrait correspondre à un besoin
# identifié (docker, sudo...), pas être ajouté "au cas où"
sudo -l
Affiche les commandes sudo autorisées pour l'utilisateur courant, et si un mot de passe est
requis pour chacune. Aucune ligne ne devrait mentionner NOPASSWD.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Ajouter un utilisateur à un groupe « au cas où il en aurait besoin plus tard » | Anticipation d'un besoin hypothétique plutôt que réel | N'accorder un droit qu'au moment où le besoin est concret et identifié |
Configurer NOPASSWD pour simplifier un script d'automatisation |
Confort de configuration au détriment de la sécurité | Préférer une clé dédiée à l'automatisation, avec des droits précisément limités à ce qu'elle doit faire |
| Multiplier les droits « root » par défaut dans des conteneurs | Simplicité apparente de tout faire tourner en root interne | Adapter l'UID/GID du conteneur au strict nécessaire, comme vu en M4 |
NOPASSWD (vu en M1) en est l'application la plus directe sur ce projet.Il transforme un accès ponctuel et confirmé (mot de passe à chaque sudo) en un privilège
permanent (accès root immédiat, sans confirmation) — un excès de droit par rapport au strict
besoin.
Parmi : publier un port en 127.0.0.1 uniquement (M2), adapter l'UID/GID d'un conteneur plutôt
que d'utiliser root par défaut (M4), ne rien exposer par défaut (M2).
Ce droit est-il strictement nécessaire à la tâche visée, ou seulement plus simple à configurer
sur le moment ?
Reprends une configuration que tu as déjà faite (ou vue dans ce wiki) et identifie si un droit y
a été accordé au-delà du strict nécessaire. Propose une version plus conforme au moindre
privilège.
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.