Droits d'accès et partages de fichiers
Ce que ce chapitre apporte
- Distinguer un droit de partage d'une permission du système de fichiers.
- Calculer un accès effectif à partir des deux mécanismes et des appartenances de groupe.
- Expliquer le cumul des autorisations et la priorité du refus explicite.
- Décrire l'héritage des permissions et savoir quand le rompre.
- Structurer une arborescence de serveur de fichiers avec des groupes.
- Expliquer ce qu'apporte un espace de noms distribué et sa réplication.
Deux mécanismes, pas un
Un dossier partagé est un dossier rendu accessible sur le réseau. Le droit de partage contrôle l'accès à la ressource lorsqu'elle est atteinte par le réseau.
Une permission NTFS s'applique directement sur le fichier ou le dossier dans le système de fichiers. Elle s'applique quel que soit le chemin d'accès, réseau ou local.
Conséquence pratique : la protection réelle des données repose sur NTFS. Le partage n'est qu'une porte d'entrée réseau.
La règle de l'accès effectif
Quand les deux mécanismes s'appliquent, l'accès final est le plus restrictif des deux.
Accès effectif par le réseau : lecture. Le partage plafonne.
Et si le même utilisateur ouvre une session sur le serveur lui-même, il obtient modification : le partage ne s'applique plus.
Une session ouverte directement sur la console du serveur ne passe par aucun réseau, donc par aucun SMB. Elle s'adresse d'emblée à NTFS, et le droit de partage n'est jamais consulté : il ne s'agit pas d'une exception, mais d'une couche qui n'a pas été traversée.
Il n'y a donc rien à retenir par cœur ici. Il suffit de se demander par où passe la requête, et la règle s'en déduit.
Le prix à payer est qu'il ne reste plus de garde-fou si les permissions NTFS sont mal posées. À choisir en connaissance de cause, et à documenter.
Cumul, refus, héritage
Trois règles gouvernent le calcul, et la deuxième prime sur la première.
Le cumul. Un utilisateur appartient souvent à plusieurs groupes. Les autorisations obtenues par ces groupes s'additionnent : lecture par l'un, modification par l'autre donne modification.
Le refus l'emporte, mais à hauteur de l'endroit où il est posé. Un refus posé sur le dossier lui-même bat toutes les autorisations. Un refus hérité d'un dossier parent, en revanche, cède devant une autorisation posée sur le dossier examiné. Le classement complet est donné plus bas, une fois l'héritage installé ; il tient en quatre rangs, et c'est le second qui surprend.
L'héritage. Un dossier transmet ses permissions à ses sous-dossiers et fichiers. C'est ce qui rend une arborescence administrable, et c'est aussi ce qui propage silencieusement une erreur.
La bonne pratique est de ne pas mettre quelqu'un dans le groupe plutôt que de lui refuser explicitement.
Quand rompre l'héritage
Rompre l'héritage sur un sous-dossier revient à en faire une exception permanente. C'est parfois nécessaire, souvent regrettable.
| Situation | Décision |
|---|---|
| Un sous-dossier plus restreint que son parent | Rompre, c'est le cas légitime |
| Un utilisateur particulier a besoin d'un accès | Ne pas rompre, créer un groupe |
| Un service veut « son » dossier isolé | Le placer ailleurs dans l'arborescence |
On ne le voit pas en regardant le sous-dossier, puisque la permission n'y est pas posée. Il faut remonter l'arborescence, et c'est exactement ce que personne ne fait quand la structure n'est pas documentée.
La figure suivante remonte l'arborescence pour chaque dossier et affiche l'accès obtenu, avec le dossier d'où vient la permission. Cliquer un dossier détaille la décision ; le bouton bascule entre un accès par le réseau et une session ouverte sur le serveur.
Partage publié sur Donnees, droit lecture
- 3 dossiers sur 7 tiennent leur sort d'une permission posée ailleurs. C'est ce qui rend une arborescence administrable, et ce qui propage une erreur sans que rien ne le signale.
- 2 dossiers sans aucun accès.
- 4 dossiers où le partage rabaisse ce que NTFS accordait. Basculer en session locale les rétablit tous d'un coup : le partage n'est qu'une porte d'entrée réseau.
- Donnees/Facturation/Paie/Historique obtient un accès alors qu'un dossier au-dessus de lui n'en a aucun. Une autorisation posée directement l'emporte sur un refus hérité : « le refus bat tout » est une formule commode et fausse.
Quatre choses se lisent sur cette figure, et aucune ne se lit sur le tableau qui la précède.
L'héritage descend. Facturation et Etude_A ne portent aucune permission. Leur accès vient de plus haut, et la figure nomme le dossier d'origine. C'est le symptôme d'Ardexia, rendu visible : une permission posée sur Donnees gouverne un dossier qui n'existait peut-être pas encore.
Un refus emporte son sous-arbre. Le refus posé sur Paie prive aussi Bulletins, qui n'a rien demandé et où rien n'est écrit.
Une autorisation explicite l'emporte sur un refus hérité. Historique obtient la lecture alors que son parent Paie n'a aucun accès. C'est le comportement réel, et il contredit la formule commode selon laquelle « le refus bat tout ».
Le partage plafonne, et seulement par le réseau. En accès réseau, Etudes tombe à la lecture alors que NTFS y accorde le contrôle total. Basculer en session locale rétablit d'un coup les quatre dossiers concernés, sans qu'aucune permission n'ait changé, et la mention du partage passe en gris : la porte n'est plus sur le chemin.
1. un refus explicite, posé sur le dossier lui-même ;
2. une autorisation explicite, posée sur le dossier lui-même ;
3. un refus hérité, en remontant du plus proche au plus lointain ;
4. une autorisation héritée, de même.
Le deuxième rang est celui qu'on oublie, et c'est celui qui explique
Historique. Un refus lointain ne reprend pas non plus ce qu'une autorisation plus proche a déjà accordé.
Organiser un serveur de fichiers
Une arborescence de partages se conçoit comme l'arborescence de l'annuaire : par usage, et de façon stable.
D:\Partagesle volume des partagesCommunGG_Touslecture et écritureServicesFacturationGG_FacturationPlateauGG_PlateauDirectionGG_DirectionEtudes2026-RefonteGG_Refontedurée de vie du projetDepotsLecture-SeuleGG_Tousdiffusion descendante, écriture réservéeTrois principes en découlent :
- Un groupe par dossier de premier niveau, jamais de permission nominative.
- Deux groupes quand deux usages coexistent :
DL_Facturation_LectureetDL_Facturation_Modification. - Les dossiers de projet ont une date de fin. Un dossier de projet sans fin de vie devient un dossier commun qui s'ignore.
L'espace de noms distribué
Un espace de noms DFS (Distributed File System) est un chemin logique unique donnant accès à des partages hébergés sur des serveurs différents, sans que l'utilisateur ait à connaître le nom du serveur physique.
La réplication DFS duplique le contenu d'un dossier entre plusieurs serveurs.
Le mécanisme tient en trois temps, et il est plus proche d'un aiguillage que d'un dossier. Le poste client demande le chemin logique à un serveur d'espace de noms, rôle que tiennent les contrôleurs de domaine pour un espace de noms de domaine. Ce serveur consulte sa table de correspondance et renvoie non pas les fichiers, mais une liste de cibles, chacune sous la forme d'un chemin UNC réel du type \\SRV-FIC-02\Facturation. Le poste se connecte ensuite directement à l'une de ces cibles, et tout le trafic de fichiers passe alors entre lui et le serveur retenu.
L'espace de noms ne voit donc jamais les données. Il ne fait que répondre à la question « où est-ce ? », ce qui explique à la fois sa légèreté et le fait qu'un changement de serveur devienne invisible : seule la table de correspondance change.
Sans espace de noms, les utilisateurs accèdent aux partages par \\SRV-FIC-01\Facturation. Le jour où le serveur est remplacé, il faut modifier tous les raccourcis, toutes les stratégies de lecteurs réseau, et toutes les habitudes.
Avec un espace de noms, ils accèdent à \\ardexia.lan\Partages\Facturation. Le serveur derrière peut changer sans que personne ne s'en aperçoive.
\\ardexia.lan\Partagesle chemin logique, stableFacturation\\SRV-FIC-01\FactuPlateau\\SRV-FIC-01\PlateauArchives\\SRV-FIC-02\ArchBeauvais\\SRV-FIC-03\ArchAmiens, répliqueCe que la figure montre, et qu'un dossier ordinaire ne montrerait pas : la colonne de gauche et celle de droite ne sont pas la même chose. À gauche, un nom que rien n'oblige à changer. À droite, des serveurs qu'on remplace tous les cinq ans.
Archives porte deux cibles pour un seul nom. Ce n'est pas un doublon : c'est la même donnée répliquée sur deux laboratoires, et le client est dirigé vers celle de son site. Aucun utilisateur n'a jamais à savoir laquelle il utilise.
La réplication répond à la disponibilité et à la proximité. Elle ne répond en rien à la perte de données, qui est l'objet du chapitre suivant.
Exercices type
Partage en lecture, NTFS en modification. Que peut faire l'utilisateur ?
Par le réseau : lecture. Le plus restrictif des deux mécanismes l'emporte, et c'est ici le partage qui plafonne.
En session locale sur le serveur : modification. Le droit de partage ne s'applique qu'aux accès réseau.
Ce second point est ce qui rend le réglage trompeur : on croit avoir restreint l'accès, alors qu'on n'a restreint qu'un chemin d'accès.
Un utilisateur est dans deux groupes, l'un en lecture, l'autre en modification. Que se passe-t-il ?
Les autorisations se cumulent : il obtient modification.
Sauf si un refus explicite est posé sur le dossier lui-même, pour l'un de ses groupes ou pour son compte. Dans ce cas, le refus l'emporte et il n'a rien.
La réserve, et c'est le rang 2 du classement : si le refus vient d'un dossier parent alors qu'une autorisation est posée sur le dossier examiné, c'est l'autorisation qui gagne. Un refus ne descend donc pas aussi loin qu'on le croit.
C'est pour cela qu'on évite les refus explicites : ils cassent une règle simple et prévisible, et rendent le diagnostic long.
Pourquoi ne jamais poser de permission sur un compte nominatif ?
Parce que la permission survit à la personne. Le jour où elle change de poste ou quitte l'entreprise, il faut se souvenir que ce dossier-là portait son nom, et le retrouver.
C'est précisément la plainte d'Ardexia : « il devient compliqué de vérifier que tous ses accès ont bien été supprimés ».
Avec des groupes, la vérification est immédiate et automatisable : on liste les appartenances du compte, et il n'y a pas d'autre endroit à regarder. C'est cette propriété qui rend la revue des droits possible.
Un sous-dossier doit être plus ouvert que son parent. Comment faire ?
D'abord se demander si c'est légitime. Un sous-dossier plus ouvert que son parent est presque toujours le signe qu'il est au mauvais endroit dans l'arborescence.
Si le besoin est réel, deux options :
Le déplacer ailleurs, sous un parent dont les droits correspondent. C'est la solution propre, et elle laisse l'arborescence lisible.
Rompre l'héritage et poser des permissions spécifiques. Cela fonctionne, et cela crée une exception qu'il faudra se rappeler. À documenter, sans quoi elle deviendra un mystère.
Quel intérêt d'un espace de noms si l'on n'a qu'un seul serveur de fichiers ?
Le jour où il y en aura deux, ou le jour où celui-ci sera remplacé.
Un espace de noms découple le chemin utilisé par les utilisateurs du serveur qui héberge réellement les données. Migrer devient une opération invisible : on ajoute la nouvelle cible, on retire l'ancienne, personne ne change ses raccourcis.
Le mettre en place tant qu'il n'y a qu'un serveur coûte une heure. Le mettre en place après coup suppose de reprendre tous les lecteurs réseau et toutes les habitudes de deux cent cinquante personnes.
La réplication DFS protège-t-elle contre un rançongiciel ?
Non, et elle aggrave même la situation.
Un rançongiciel chiffre les fichiers. La réplication considère un chiffrement comme une modification légitime et la propage à l'autre serveur. Les deux copies sont perdues, et plus vite qu'avec une seule.
Ce qui protège, c'est une sauvegarde hors ligne ou immuable, dont le contenu ne peut pas être réécrit par la machine compromise. C'est l'objet du chapitre suivant, et la règle 3-2-1 est faite pour cela.
Formule à retenir : la réplication répond à la disponibilité, la sauvegarde répond à la perte.
Vérification
1.Un utilisateur accède à un partage depuis le réseau. Quel accès obtient-il ?
2.Quel élément se prononce en premier dans la décision d'accès ?
3.Pourquoi éviter les permissions nominatives ?
4.La réplication d'un serveur de fichiers tient-elle lieu de sauvegarde ?
La méthode
- Nommer le mécanisme dont on parle : droit de partage ou permission NTFS. La moitié des malentendus vient de là.
- Calculer l'accès effectif en trois temps : cumul des autorisations, refus explicite prioritaire, puis le plus restrictif du partage et de NTFS.
- Vérifier le chemin d'accès : réseau ou session locale. Le partage ne s'applique qu'au premier.
- Remonter l'arborescence devant un accès inattendu. La permission fautive est presque toujours sur un dossier parent.
- Ne jamais poser de permission nominative, et se garder des refus explicites.
- Un dossier de premier niveau, un groupe. Deux groupes si deux usages coexistent.
- Publier par un espace de noms, même avec un seul serveur.
- Ne jamais appeler une réplication une sauvegarde.
Synthèse
- Droit de partage : accès réseau uniquement. Permission NTFS : tous les chemins d'accès.
- Accès effectif par le réseau = le plus restrictif des deux.
- Les autorisations se cumulent entre groupes. Le refus, lui, se classe : posé sur le dossier, il bat toute autorisation ; hérité d'un parent, il cède devant une autorisation posée sur le dossier examiné.
- L'héritage rend l'arborescence administrable et propage les erreurs. On ne le rompt que pour restreindre.
- Un groupe par dossier, jamais de permission nominative : c'est ce qui rend la revue des droits possible.
- Un espace de noms DFS découple le chemin utilisateur du serveur physique et rend les migrations invisibles.
- La réplication n'est pas une sauvegarde : elle propage aussi les suppressions et les chiffrements.
Mettre en pratique
L'accès effectif quand plusieurs règles se contredisent, et le plafond du partage.
- L'accès qu'un utilisateur obtient vraimentNiveau 3
- Le plafond que pose un partageNiveau 2
- Débogage : un refus hérité qui gagne tropNiveau 4