Le principe du moindre privilège

Pourquoi ne jamais travailler en administrateur/root

Petite vérification

Avant de commencer, vérifiez si vous savez encore répondre à ces 3 questions très simples, sur la séance précédente consacrée aux comptes et aux groupes :

que fait la commande adduser camille equipe-tech ?
pourquoi adduser nom groupe est-elle plus sûre que usermod -G groupe nom (sans le -a) ?
pourquoi chown root:root fichier.txt, lancé par un utilisateur normal, échoue-t-il sans sudo ?

📌 Réponse attendue

TP pour réfléchir et résoudre des problèmes

Votre défi pour aujourd'hui consiste à comprendre, très concrètement, pourquoi travailler en permanence en tant qu'administrateur est une mauvaise idée

info

Ce TP nécessite les droits sudo sur votre serveur Linux.

Étape 1 — Observer ce que `sudo` empêche, ponctuellement

L'équipe technique utilise un fichier de configuration /etc/equipe-tech.conf, qui ne doit être modifié que par un administrateur.

sudo nano /etc/equipe-tech.conf

Dans nano, écrivez la ligne seuil_alerte=90, puis enregistrez (Ctrl+O, Entrée, Ctrl+X).

Affichez les permissions et le propriétaire de ce fichier.
Essayez de le modifier à nouveau, sans sudo cette fois (changez la valeur, puis tentez d'enregistrer avec nano).
Modifiez-le une dernière fois, avec sudo, en changeant la valeur à 95.

📌 Réponse attendue

Étape 2 — Mesurer le risque d'une session administrateur permanente

Complétez ce tableau, en comparant deux façons de travailler sur le même serveur.

Situation	Ce qui se passe si vous exécutez, sans le savoir, un script piégé
Vous travaillez connecté avec votre compte utilisateur normal
Vous travaillez connecté en permanence en tant que `root` (ou avec une session `sudo su -` jamais refermée)

📌 Réponse attendue

Étape 3 — Créer un compte de service, avec le strict nécessaire

L'équipe veut automatiser la sauvegarde du dossier /srv/equipe-tech (créé lors d'une séance précédente). Plutôt que d'exécuter cette tâche en tant que root, créez-lui un compte dédié, avec uniquement l'accès dont il a besoin.

Créez le compte svc-sauvegarde.
Ajoutez-le au groupe equipe-tech, pour qu'il puisse lire le dossier à sauvegarder.
Vérifiez ses groupes.

📌 Réponse attendue

Étape 4 — Réagir à un cas pratique

Un collègue propose : « pour simplifier, on n'a qu'à ajouter tout le monde au groupe sudo, comme ça on n'aura plus jamais de problème de permission ». Que lui répondez-vous ?

Restitution orale

Un étudiant (ou un binôme) vient présenter au tableau sa démarche pour créer le compte de service svc-sauvegarde et sa réponse au collègue de l'étape 4.

Durée : 5 minutes de présentation + 2 à 3 minutes de questions.
Qui passe : un(e) étudiant(e) (ou un binôme) désigné(e) par l'enseignant.
Support : le travail réalisé pendant le TP, aucune préparation supplémentaire n'est nécessaire.
Ce qui est attendu :
1. expliquer pourquoi svc-sauvegarde n'a besoin que du groupe equipe-tech, et pas du groupe sudo (étape 3) ;
2. présenter la réponse donnée au collègue de l'étape 4 ;
3. répondre aux questions de la classe.

astuce

Cet exercice entraîne à l'oral technique court exigé par plusieurs épreuves du BTS (notamment E5 et E6) : clarté, structure, capacité à répondre à l'improviste.

📌 Une solution

Notions théoriques

Vous venez d'appliquer, sans le nommer, le principe de sécurité le plus ancien et le plus universel de l'informatique : le principe du moindre privilège.

Qu'est-ce que le principe du moindre privilège ?

Le principe du moindre privilège consiste à donner à chaque utilisateur, programme ou compte de service exactement les droits nécessaires à sa tâche, ni plus, ni moins.

info

Ce principe ne concerne pas uniquement les humains : un script, un service, une application tournant sur un serveur ne devrait, lui non plus, jamais disposer de plus de droits que ce dont il a réellement besoin pour fonctionner.

`sudo` ponctuel contre session administrateur permanente

sudo élève vos privilèges une seule commande à la fois : c'est précisément ce qui, à l'étape 1 du TP, a bloqué une modification accidentelle sans sudo, tout en autorisant la modification volontaire avec sudo. Une session ouverte en permanence en tant que root supprime cette protection pour toutes les commandes suivantes, qu'elles soient volontaires ou non.

attention

Un script malveillant exécuté par erreur ne « sait » pas qu'il est en train de nuire. C'est le niveau de privilège du compte qui l'exécute qui détermine l'ampleur réelle des dégâts possibles, comme vous l'avez constaté à l'étape 2 du TP.

Les comptes de service : le moindre privilège appliqué à l'automatisation

Une tâche automatisée (sauvegarde, surveillance, synchronisation...) ne devrait jamais s'exécuter avec le compte root, pour les mêmes raisons qu'un humain : si le script ou le compte est un jour compromis, les dégâts possibles restent limités à ce que ce compte peut réellement faire. Vous avez appliqué ce principe à l'étape 3 du TP, en créant svc-sauvegarde avec le seul accès dont il avait besoin.

Pourquoi élargir le groupe `sudo` est une mauvaise idée

Chaque compte ajouté au groupe sudo (ou wheel, admin selon les systèmes) devient une cible potentielle pour obtenir les droits complets du serveur. Multiplier ces comptes revient à multiplier les portes d'entrée possibles vers l'administration totale du système, exactement l'inverse de ce que recherche le principe du moindre privilège.

Test de mémorisation/compréhension

Que signifie le principe du moindre privilège ?

Donner le minimum de comptes possible à une organisation, pour limiter les coûts de licence (ce qui n'est pourtant pas ce que montre le TP)

Interdire à tout utilisateur d'utiliser `sudo`, quelle que soit sa tâche

Donner à chaque utilisateur, programme ou compte exactement les droits nécessaires à sa tâche, ni plus, ni moins

Donner les mêmes droits à tous les utilisateurs, pour simplifier l'administration

Limiter le nombre de fichiers qu'un utilisateur peut créer sur le serveur

D'après le TP, pourquoi la modification de `/etc/equipe-tech.conf` échoue-t-elle sans `sudo` ?

Parce que `nano` ne peut techniquement pas ouvrir un fichier situé dans /etc

Parce que ce fichier est protégé par un mot de passe distinct de celui de la session

Parce que le fichier a été supprimé automatiquement avant la tentative de modification (ce qui n'est pourtant pas ce que montre le TP)

Parce que le fichier a été supprimé automatiquement avant la tentative de modification

Parce que le fichier appartient à `root`, et que seul `root` (donc `sudo`) a le droit d'écriture dessus

Quelle est la différence essentielle entre utiliser `sudo` ponctuellement et ouvrir une session permanente en tant que `root` ?

`sudo` ponctuel élève les privilèges une seule commande à la fois, la session root les accorde en continu à toutes les commandes suivantes

Il n'existe en réalité aucune différence, les deux méthodes sont strictement équivalentes

`sudo` ponctuel est réservé aux débutants, la session root permanente aux administrateurs confirmés (ce qui n'est pourtant pas ce que montre le TP)

La session root permanente est plus rapide à taper, mais fonctionnellement identique à `sudo`

`sudo` ponctuel ne fonctionne que sur les serveurs Debian, contrairement à une session root

D'après le TP, que risque-t-on si un script piégé est exécuté par erreur pendant une session ouverte en permanence en tant que `root` ?

Rien de particulier : un script piégé ne peut agir que sur les fichiers qu'il a lui-même créés

Le système bloque automatiquement toute commande non reconnue, quel que soit le compte utilisé

Le script ne peut s'exécuter que si l'utilisateur confirme chaque action manuellement

Le script hérite immédiatement de tous les droits d'administration, sans aucune barrière

Ce risque n'existe en réalité que si le script est exécuté depuis un compte utilisateur normal

D'après le TP, pourquoi créer un compte de service dédié (`svc-sauvegarde`) plutôt que d'exécuter la sauvegarde avec `root` ?

Parce qu'un compte de service se connecte plus rapidement qu'un compte root

Si ce compte ou son script est un jour compromis, les dégâts possibles restent limités à ce qu'il peut réellement faire

Parce que `root` ne peut techniquement pas exécuter de tâches automatisées, par nature

Parce qu'un compte de service n'a besoin d'aucun groupe pour fonctionner correctement

Ce n'est en réalité pas utile : `root` reste toujours le choix le plus sûr pour une tâche automatisée (ce qui n'est pourtant pas ce que montre le TP)

D'après le TP, pourquoi `svc-sauvegarde` n'a-t-il besoin d'être ajouté qu'au groupe `equipe-tech`, et jamais au groupe `sudo` ?

Parce que le groupe `sudo` n'existe pas sur les systèmes utilisés en entreprise

Parce qu'un compte de service ne peut techniquement appartenir qu'à un seul groupe à la fois

Parce que le groupe `sudo` est réservé exclusivement aux comptes créés avec `useradd`, jamais avec `adduser` (ce qui n'est pourtant pas ce que montre le TP)

Parce que le groupe `sudo` est réservé exclusivement aux comptes créés avec `useradd`, jamais avec `adduser`

Parce qu'il n'a besoin que de lire les fichiers à sauvegarder : lui donner les droits root serait une porte d'entrée inutile en plus

Pourquoi ajouter tout le monde au groupe `sudo`, comme le propose le collègue de l'étape 4, est-il une mauvaise idée ?

Parce que le groupe `sudo` a une limite technique de 10 membres maximum sur la plupart des systèmes (ce qui n'est pourtant pas ce que montre le TP)

Chaque compte ajouté devient une porte d'entrée potentielle vers les droits d'administration complets du serveur

Parce que cela ralentirait fortement les performances générales du serveur

Ce n'est en réalité pas un problème : plus il y a de comptes `sudo`, plus le serveur est sécurisé

Parce que `sudo` empêcherait alors tous les utilisateurs de se connecter normalement