Est-ce une approche recommandée / valide pour les autorisations de serveur de fichiers?

Les serveurs de fichiers sont une réalité de l'informatique et je suis curieux de savoir s'il existe des pratiques généralement acceptées (j'hésite à utiliser le mot «meilleur» ici) pour la façon dont vous créez des groupes et appliquez des autorisations pour gérer l'accès client à un dossier partagé sur un serveur de fichiers.

Dans mon travail actuel, j'ai fini par hériter d'un tas de façons différentes de le faire, allant de dizaines de groupes sur les listes de contrôle d'accès à simplement mettre des utilisateurs individuels directement sur le système de fichiers. Ma tâche consistait à nettoyer le gâchis et à trouver une sorte de manière standardisée d'aborder cela dans toute l'entreprise (grand environnement, 150 000 personnes, 90 000 ordinateurs clients, 100 serveurs de fichiers).

D'après ma compréhension du problème, il semble que vous ayez au moins besoin d'un groupe par niveau d'accès requis par ressource sécurisée. Ce modèle semble donner le plus de flexibilité dans la mesure où vous n'avez pas besoin de toucher à nouveau aux autorisations du système de fichiers, sauf si vous devez prendre en charge un niveau d'accès différent. L'inconvénient est que vous créerez plus de groupes qu'avec la réutilisation du même groupe sur plusieurs ressources partagées.

Voici un exemple montrant ce que je veux dire:

Il existe un partage appelé "Résultats des tests" sur un serveur de fichiers nommé FILE01 et vous avez des gens qui ont besoin d'un accès en lecture seule, d'un accès en lecture-écriture et d'un contrôle total. 1 ressource sécurisée * 3 niveaux d'accès = 3 groupes de sécurité. Dans notre environnement AD, nous les créons en tant que groupes universels afin de pouvoir facilement ajouter des utilisateurs / groupes à partir de n'importe quel domaine de la forêt. Étant donné que chaque groupe fait uniquement référence à un dossier partagé et à un niveau d'accès, les noms de groupe incorporent ces éléments de données "clés" et les autorisations sont donc:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

En règle générale, nous inclurions également le compte SYSTEM intégré et les administrateurs intégrés avec un accès de contrôle total. Toute modification de qui obtient réellement quel accès à ce partage peut maintenant être gérée en utilisant les appartenances aux groupes plutôt que d'avoir à toucher à l'ACL (soit en ajoutant des groupes de «rôles» représentant des rôles commerciaux spécifiques tels que les gestionnaires, les techniciens, les analystes de l'assurance de la qualité, etc. ou simplement individuels utilisateurs pour un accès unique).

Deux questions:

1) Est-ce réellement une approche recommandée ou valide pour gérer les autorisations ou me manque-t-il une solution plus simple et plus élégante? Je serais particulièrement intéressé par toutes les solutions qui utilisent l'héritage mais conservent la flexibilité de ne pas avoir à ré-ACL de grandes parties des systèmes de fichiers lorsque les choses changent.

2) Comment gérez-vous les autorisations du serveur de fichiers et la structure des groupes dans votre environnement? Points bonus pour ceux qui travaillent également dans de grands environnements.

Mon approche consiste à ne pas utiliser les autorisations de fichier au niveau du fichier / répertoire; utiliser les autorisations de niveau de partage de fichiers et définir le lecteur de données du système de fichiers du serveur entier sur Tout le monde (qui devient théorique).

Au fil des ans (10+), j'ai constaté que les autorisations NTFS sont plus complexes et entraînent plus d'erreurs. Si les autorisations sont mal définies ou que l'héritage est rompu, vous exposez les données et leur difficulté à les trouver et à les voir. De plus, vous êtes exposé au problème de déplacement / copie ... les utilisateurs qui déplacent des fichiers déplacent également l'ACL du fichier, tandis que la copie hérite de l'ACL de destination.

Utilisez vos groupes de lecture / écriture de la même manière, mais sur l'ensemble du partage de fichiers à l'aide de Comp Mgmt MMC. Ne faites pas le plein ... les utilisateurs se tireront des connaissances partielles / meilleures intentions.

Cette approche n'est pas mauvaise. En règle générale, n'utilisez jamais d'utilisateurs individuels pour ajouter des autorisations - utilisez un groupe. Les groupes peuvent cependant être utilisés sur plusieurs ressources. Par exemple, HR peut avoir un accès RW aux fichiers tandis que MANAGERS peut avoir R. Vous pouvez également configurer l'énumération basée sur l'accès. Jetez un œil à la webémission suivante:

Webcast TechNet: Série d'administration Windows Server 2003 (partie 4 sur 12): Gestion de groupe (niveau 200)

L'énumération basée sur l'accès peut également vous faciliter la vie:

Énumération basée sur l'accès

ABE peut aider à réduire le nombre d'actions différentes que vous devez administrer.

Votre approche est essentiellement la façon dont je l'aborderais.
Les seules choses que j'ajouterais sont les suivantes:

1) J'ajouterais à votre schéma de "rôles" en évaluant ce dont ils ont besoin sur plusieurs serveurs et non sur un seul serveur que vous allez probablement rencontrer des valeurs aberrantes, mais ma théorie avec ceux-ci est que lorsque vous les rencontrez, créez un autre groupe. d'après mon expérience, où il y a une valeur aberrante, il y en a beaucoup.

2) Je réévaluerai FORTEMENT le besoin de groupes universels pour tout, car vous emportez une réplication avec eux, car les membres et les groupes à l'intérieur du groupe universel sont répliqués sur les serveurs du catalogue global, tandis qu'avec le domaine local et global, seul le groupe est répliqué sur les serveurs de catalogue global. Donc, si vous effectuez un changement dans un groupe universel, cela déclenche une réplication, alors qu'avec global et local, ce n'est pas le cas.

Votre méthode d'utilisation du groupe de ressources pour chaque niveau d'accès est correcte. La seule chose que je considérerais est l'utilisation de groupes locaux de domaine pour les ressources. Vous n'avez pas nécessairement besoin d'utiliser des groupes universels si vous créez des groupes de ressources spécifiques au serveur.

L'inconvénient de l'utilisation des groupes locaux de domaine pour les ressources est que vous vous retrouvez avec plus de groupes au total. L'avantage est que vous avez moins de problème avec la réplication, comme l'a noté Zypher.

L'approche proposée semble assez solide. Une chose à surveiller est la façon dont vous avez initialement configuré les partages de fichiers. La pratique recommandée consiste à avoir un seul partage de niveau supérieur, contenant des sous-dossiers auxquels vous attribuez ensuite les autorisations de groupe. NTFS peut ensuite contourner le "Dossier transversal / Exécuter le fichier" sur le dossier de niveau supérieur et accorder l'accès au sous-dossier.

La structure ressemblerait alors à \ servername \ sharename \ group-folder, les autorisations de partage ne devant être définies que sur le dossier "sharename" et les autorisations NTFS réelles définies sur le dossier "group-folder".

Votre serveur de fichiers sera également plus performant avec ce type de configuration.

Général, je ferais une convention de dénomination pour les groupes de telle sorte que le nom du groupe soit le même que le nom du dossier du groupe (avec FC / RW / RO ajouté si vous le souhaitez), et collez l'UNC dans le dossier dans la description du groupe (afin que votre script de connexion puisse le relire et définir un mappage de lecteur de cette manière, ainsi que pour voir plus facilement quels dossiers partagés s'appliquent à quels groupes).

La pratique standard que j'utilise pour le serveur de fichiers Windows depuis Windows 2000 (présentée dans la série Mastering Windows Server de Mark Minasi, alors regardez-y pour plus d'informations) consiste à utiliser des groupes locaux sur le serveur de fichiers lui-même pour l'imbrication.

Par exemple, considérons un serveur de fichiers nommé KERMIT dans un domaine appelé MUPPETS.

Supposons que KERMIT possède quelques partages de fichiers:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Créez des groupes locaux à KERMIT pour l'accès et donnez-leur des autorisations sur le système de fichiers exactement comme vous l'avez spécifié (c'est-à-dire un groupe par niveau d'accès par partage)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Étant donné qu'il s'agit de groupes locaux, vous pouvez y mettre tous les autres groupes ou utilisateurs que vous souhaitez - groupes locaux de domaine, groupes globaux, groupes universels, comptes d'utilisateurs de n'importe quel domaine de votre forêt. La gestion des droits est désormais locale pour les groupes du serveur de fichiers plutôt que pour le système de fichiers ou l'AD.

Cela ajoute une couche supplémentaire à la gestion de vos groupes, mais cela a l'avantage de permettre (par exemple) aux administrateurs du site de gérer leurs propres serveurs de fichiers sans avoir besoin de plus que des droits d'administrateur sur ce serveur de fichiers. Si vous avez une sorte de structure de succursale fédérée, où chaque bureau fait sa propre chose avec ses serveurs, cela peut être un réel avantage. Vous ne voudrez peut-être pas donner des droits d'administrateur AD à quelques dizaines d'administrateurs de sites locaux.

Il empêche également votre AD d'être encombré de nombreux groupes (un groupe par niveau d'accès par partage et par serveur peut s'additionner très rapidement) et minimise la réplication de groupe entre les GC. Il vous permet de réserver vos groupes AD pour des rôles plutôt que des autorisations.

Si votre environnement est rigoureusement standardisé et que tous les serveurs de fichiers sont identiques et répliqués, il s'agit évidemment d'une couche supplémentaire de groupes dont vous n'avez pas besoin. De plus, si vous savez que vous avez besoin d'un groupe AD particulier pour avoir les mêmes droits sur un partage qui existe sur chaque serveur de fichiers, vous aurez besoin d'une certaine automatisation pour le maintenir.

En résumé, plus vos serveurs de fichiers sont différents les uns des autres, plus il est logique d'utiliser des groupes locaux de machines. Plus ils sont similaires, plus vous souhaitez utiliser le système que vous utilisez actuellement.

J'envisage une migration de NetWare vers Windows Server 2008, donc cela m'a beaucoup préoccupé récemment. Server 2008 (et dans une certaine mesure Server 2003R2) ont de très belles fonctionnalités qui facilitent vraiment cette transition. Server 2008 est livré avec une énumération basée sur l'accès prête à l'emploi. Il s'agit d'une fonctionnalité très intéressante qui permet aux utilisateurs de ne voir que les répertoires dans lesquels ils ont des droits. Si vous avez une part comme ...

\\ user-home-srv \ homes \

Sans ABE, l'utilisateur final verrait des dizaines / centaines / milliers de répertoires. Avec ABE, l'utilisateur final n'en verrait qu'un seul. Il en va de même pour les actions partagées. Avec ABE, vous pouvez avoir un seul volume énorme pour tous vos répertoires départementaux si vous le souhaitez, et ne pas spammer les utilisateurs avec des répertoires dans lesquels ils ne peuvent pas accéder. Bien qu'il ne s'agisse pas d'un problème d'ACL, il est quelque peu lié, donc je le soulève.

L'héritage ACL est une autre chose que Server 2008 semble faire mieux que ses versions antérieures. Il semble juste plus rapide de propager jusqu'à la feuille un changement d'ACL au sommet d'un grand arbre.

En raison de notre héritage Netware, nous avons un grand nombre de groupes qui sont nommés en fonction de qui est en eux, avec quelques-uns nommés pour ce à quoi ils donnent accès. Pour les répertoires disposant d'un accès réglementé, nous utilisons également la nomenclature "RO" "Full".

Nous avons un volume monolithique "partagé" (toujours sur NetWare, mais nous prévoyons de le faire monolithique lorsque nous passerons à Windows) qui est le volume partagé unique pour les 4 400 employés et contient plus de 3,5 millions de fichiers. Les répertoires de niveau supérieur sont tous des noms de département, et chaque département réglemente ce qui se passe à l'intérieur. Il y a quelques exceptions pour les très gros départements, ceux-ci ont un 2ème niveau d'annuaires avec ACL.

Lors de mon dernier emploi, nous avons même pu configurer des autorisations afin que les employés des RH qui postulent ne puissent pas voir leurs propres données d'application sur leur serveur. Il a fallu quelques filtres de droits d'héritage pour le faire, ce qui est similaire à la balise "héritage de bloc" sur Windows. La partie la plus délicate consistait à tout documenter, mais cela a fonctionné .

Un meilleur scénario consiste à ajouter chaque utilisateur à un seul groupe de sécurité pour le rôle de travail de l'utilisateur. Le rôle est alors l'accès délégué en cas de besoin.

De même, un dossier partagé doit être autorisé à utiliser des groupes de sécurité "ressource", comme votre exemple "FILE01-Test Results-RW". Celui-ci contiendra les rôles de poste, les rôles de service ou d'autres groupes applicables.

L'avantage de cette conception est que vous déléguez l'accès par groupe (équipe, service, etc.), et non un accès unique qui peut être difficile à suivre. Lorsqu'un utilisateur passe à un autre service, vous devez nettoyer tous les anciens accès.

L'inconvénient est que les groupes peuvent être mal utilisés. Faites des distinctions claires quant à l'utilisation des groupes, afin que les groupes de ressources affectés à un partage ne soient pas réutilisés comme s'il s'agissait de groupes ministériels, créant un désordre d'accès enchevêtré.