3.1Comptes, droits & permissions
L'essentiel en 30 secondes
- Trois briques : le compte (identité), le groupe (besoin partagé) et la permission (droit accordé sur une ressource via une ACL).
- On affecte les droits aux groupes, jamais aux personnes une par une : arrivées et départs se gèrent par simple appartenance.
- Moindre privilège : chacun n'a que le strict nécessaire ; un compte administrateur de trop est un risque, pas un confort.
Mini-cas filé — Sofiane accueille une comptable à Alger
Sofiane, technicien support devenu administrateur systèmes dans une PME de distribution à Alger, accueille une nouvelle comptable. La tentation serait de cocher dix cases d'accès une par une ; il applique plutôt la logique de la section. Il crée un groupe « Comptabilité », lui affecte les permissions sur le partage comptable, puis ajoute simplement la nouvelle venue à ce groupe : elle hérite d'un coup de tous les bons accès. Il vérifie qu'aucun compte ne détient de droits d'administrateur inutiles et note le réflexe : les droits vont aux groupes, on gère les personnes par appartenance.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 3.1.
1. Comptes, groupes, permissions — les trois briques
Trois briques structurent la gestion des accès : le compte utilisateur (une identité), le groupe (un ensemble d'utilisateurs qui partagent un besoin) et la permission (ce qu'on a le droit de faire sur une ressource, via une ACL). La règle d'or tient en une phrase : on affecte les droits aux groupes, pas aux personnes une par une. Sofiane pose toujours ces trois briques avant de distribuer le moindre accès.
2. Pourquoi passer par les groupes
Donner un accès à « Marie », puis à « Karim », puis à « Sonia » devient vite ingérable. On crée un groupe « Comptabilité », on lui donne les droits sur le partage comptable, et on ajoute ou retire les personnes du groupe. Un nouvel arrivant hérite instantanément des bons accès ; un départ se règle en une seule action, sans risque d'oublier un droit qui traînerait.
3. Le moindre privilège
Le principe du moindre privilège : chacun n'a que les droits nécessaires à son travail, ni plus. On évite de distribuer des droits d'administrateur « pour être tranquille » — un compte trop puissant est un risque majeur si son mot de passe fuit, si l'utilisateur se trompe ou si un malware s'en empare. Sofiane garde cette règle comme boussole à chaque demande d'accès.
🔎 Exemple concret — 🔎 Exemple concret — Un nouvel arrivant à la comptabilité
Sonia rejoint la comptabilité de la PME. Sofiane compare deux façons de faire :
X Ajouter Sonia manuellement a chaque dossier/partage/appli
OK Ajouter Sonia au groupe "Comptabilite"
-> elle herite instantanement de TOUS les bons accesLecture : le groupe porte les droits ; on ne touche qu'à l'appartenance de Sonia.
Leçon : à son départ, la retirer du groupe suffit — aucun accès oublié ne traîne.
Vocabulaire de la section
- Compte utilisateur
- Identité numérique d'une personne, avec ses identifiants.
Exemple simple : Sofiane crée un compte pour chaque nouvel arrivant.
Ce que ce n'est pas : un groupe qui rassemble plusieurs identités.
Réflexe : une personne → un compte.
- Groupe
- Ensemble d'utilisateurs partageant un même besoin d'accès ; il porte les permissions.
Exemple simple : Le groupe « Comptabilité » reçoit les droits sur le partage comptable.
Ce que ce n'est pas : un droit posé pour une seule personne nommée.
Réflexe : un besoin partagé → un groupe.
- Permission (ACL)
- Droit accordé sur une ressource (lecture, écriture…) via une liste de contrôle d'accès.
Exemple simple : Sofiane met le groupe en lecture/écriture sur le dossier RH.
Ce que ce n'est pas : la bande passante allouée à un poste.
Réflexe : droit sur une ressource → ACL.
- Moindre privilège
- N'accorder que les droits strictement nécessaires au travail de chacun.
Exemple simple : Sofiane refuse l'admin « pour être tranquille ».
Ce que ce n'est pas : donner les droits d'administrateur à tous les utilisateurs.
Réflexe : le strict nécessaire → moindre privilège.
- Compte administrateur
- Compte à droits étendus, à réserver et à protéger particulièrement.
Exemple simple : Sofiane n'utilise l'admin que pour les tâches d'administration.
Ce que ce n'est pas : un compte standard utilisé au quotidien.
Réflexe : droits étendus → à protéger.
En pratique — En pratique — Concevoir un modèle de droits
- Listez trois services (comptabilité, RH, direction) et leurs besoins d'accès, comme Sofiane.
- Créez un groupe par besoin et attribuez-lui les permissions sur les ressources.
- Placez chaque utilisateur dans le ou les bons groupes, sans droit individuel.
- Vérifiez qu'aucun compte ne dispose de droits d'admin inutiles.
Script pas-à-pas — poser les droits d'un service comme Sofiane (4 min)
1) Listez les ressources à ouvrir (partages, applications). 2) Créez un groupe qui porte le besoin (ex. « Comptabilité »). 3) Affectez à ce groupe les permissions sur chaque ressource, au bon niveau (lecture ou lecture/écriture). 4) Ajoutez les personnes au groupe, sans droit individuel. 5) Vérifiez qu'aucun compte ne garde un droit d'admin inutile.
Gardez ce modèle : les arrivées et départs deviennent une simple appartenance à modifier, sans chasse aux droits oubliés.
Modèle copier-coller — ma matrice des droits
Ressource -> Groupe -> Niveau (lecture / ecriture)
Compta partage -> groupe "Comptabilite" -> lecture/ecriture
RH partage -> groupe "RH" -> lecture seule
Tous les autres -> aucun acces
Regle : droits AUX GROUPES ; personnes par appartenance ; moindre privilegeUn nouvel arrivant
Sofiane ajoute le nouvel employé au bon groupe : il hérite de tous ses accès d'un coup.
Un départ
Sofiane retire la personne du groupe : plus aucun accès oublié ne traîne.
Une demande d'admin
Un service réclame les droits d'administrateur : Sofiane applique le moindre privilège et refuse l'excès.
Un dossier confidentiel
Sofiane vérifie qu'aucun compte standard ne peut atteindre les données confidentielles du service RH.
✓ Bonnes pratiques
- Donner les droits aux groupes, pas aux personnes.
- Appliquer le moindre privilège à chaque demande d'accès.
- Réserver et protéger les comptes administrateur.
✗ Pièges fréquents
- Attribuer des accès individuels partout (ingérable).
- Distribuer l'admin « pour être tranquille ».
- Oublier de retirer les droits d'un partant.
Points clés à retenir
- Compte (identité), groupe (besoin partagé), permission (droit sur une ressource).
- On affecte les droits aux groupes ; on gère les personnes par appartenance.
- Moindre privilège : juste ce qu'il faut, pas plus.
- Un compte admin de trop est un risque, pas un confort.
Défi 48h — appliquez demain
Comme Sofiane, dessinez la matrice des droits d'un service : un groupe, les permissions qu'il porte (lecture ou lecture/écriture) et les personnes rattachées par appartenance. Vérifiez qu'aucun compte ne détient d'admin inutile et écrivez en une phrase pourquoi les droits vont aux groupes plutôt qu'aux individus.
- Je peux expliquer les trois briques : compte, groupe, permission.
- J'affecte les droits aux groupes et je gère les personnes par appartenance.
- J'applique le moindre privilège et je protège les comptes admin.
Questions fréquentes
Pourquoi ne pas simplement donner l'admin à tout le monde ?
Parce qu'un compte administrateur peut tout modifier ou détruire : une erreur, un malware ou un mot de passe volé y font des dégâts maximaux. Le moindre privilège limite la casse et réduit la surface d'attaque.
Que se passe-t-il si des permissions se cumulent via plusieurs groupes ?
Les droits s'additionnent, et un refus explicite l'emporte en général sur une autorisation. D'où l'intérêt d'un modèle simple : trop de groupes qui se chevauchent rendent les accès imprévisibles.
En bonne pratique, à qui attribue-t-on les permissions sur une ressource ?