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.
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 explicite l'emporte. Un refus posé explicitement bat toutes les autorisations, quelle qu'en soit l'origine.
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.
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:\Partages
├── Commun (tous les salariés, lecture et écriture)
├── Services
│ ├── Comptabilite (GG_Comptabilite)
│ ├── Production (GG_Production)
│ └── Direction (GG_Direction)
├── Projets
│ └── 2026-Refonte (groupe dédié, durée de vie du projet)
└── Depots
└── Lecture-Seule (diffusion descendante, écriture réservée)
Trois principes en découlent :
- Un groupe par dossier de premier niveau, jamais de permission nominative.
- Deux groupes quand deux usages coexistent :
DL_Compta_LectureetDL_Compta_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 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.
Sans espace de noms, les utilisateurs accèdent aux partages par \\SRV-FIC-01\Comptabilite. 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 à \\neolink.local\Partages\Comptabilite. Le serveur derrière peut changer sans que personne ne s'en aperçoive.
\\neolink.local\Partages
|
|-- Comptabilite --> cible : \\SRV-FIC-01\Compta
|-- Production --> cible : \\SRV-FIC-01\Prod
|-- Archives --> cibles : \\SRV-FIC-02\Arch (site de Lyon)
\\SRV-FIC-03\Arch (site de Paris, replique)
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é quelque part, sur l'un des groupes ou sur son compte. Dans ce cas, le refus l'emporte sur tout, et il n'a rien.
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 de NeoLink : « 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 trois cents 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.
La méthode
- Nomme le mécanisme dont tu parles : droit de partage ou permission NTFS. La moitié des malentendus vient de là.
- Calcule l'accès effectif en trois temps : cumul des autorisations, refus explicite prioritaire, puis le plus restrictif du partage et de NTFS.
- Vérifie le chemin d'accès : réseau ou session locale. Le partage ne s'applique qu'au premier.
- Remonte l'arborescence devant un accès inattendu. La permission fautive est presque toujours sur un dossier parent.
- Ne pose jamais de permission nominative, et évite les refus explicites.
- Un dossier de premier niveau, un groupe. Deux groupes si deux usages coexistent.
- Publie par un espace de noms, même avec un seul serveur.
- N'appelle jamais une réplication une sauvegarde.
En résumé
- 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 ; un refus explicite bat tout.
- 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.
Et ensuite ? Les accès sont maîtrisés, mais les données restent exposées à la panne, à l'erreur et au rançongiciel. Le chapitre suivant traite de ce qui reste quand tout le reste a échoué : la sauvegarde, le plan de continuité et le plan de reprise.