Я Вас прекрасно понимаю и все сложности озвученные тоже мне понятны.
Один комментарий по поводу топ менеджеров — например бухгалтера и финансисты работают в соответствии регламентов, которые определяют их деятельность и возможно тоже кто-то хотел бы видеть их работу другой. Но их работа основывается на требованиях законов, документов и т.д. Т.е. они работают по своим стандартам. Пока в ИТ не будет таких же стандартов — на технические решения будет влиять любой менеджер (причем под разных менеджеров можно даже разные решения внедрять по их пожеланию ;-) ). Поэтому я изначально и говорил, что если бы были правила на которые можно было бы ссылаться — было бы проще.
Если вы готовы идти только по своему пути развития своего файлового хранилища и четко понимаете свои проблемы, то я думаю надо тогда и думать:
1. Как автоматизировать задачу прописывания траверсов
2. Как забрать права у пользователей на удаление и перемещения папок вложенных ресурсов и промежуточных папок.
Думаю что вынесение на коллективное обсуждение этой темы будет более полезным, чем частный обмен опытом. Я давно хотел увидеть какие-то подобные решения, которые были бы определенными стандартами в данной области и на которые можно было бы ссылаться при дизайне файловых хранилищ.
Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов? Зачем пользователю который по факту не видит всей структуры папок и их содержимого (ведь мы хотим скрыть папки к которым доступа нет у пользователя) должен пробираться например на 5ый уровень вложенности чтобы увидеть папку ДОКУМЕНТАЦИЯ?
На мой взгляд когда пользователь все равно не видит этих папок, то ему удовольствия нет прыгать пять уровней непонятно для чего.
В своей практике я использую немного другую модель. Я не делаю ресурсы вложенными. Я исхожу того, что должно быть четкое правило определение ресурса. Я определяю, что один ресурс — это один набор ACL. Если есть потребность для какой-то части ресурса изменить ACL, то это сигнал к тому, что информационный ресурс надо разделить на два ресурса. Т.е. модель файловых ресурсов с точки зрения ACL получается плоской и нет никаких вложенностей. Все ресурсы всегда находятся на одном уровне вложенности (т.е. всегда размещаются рядом и не надо искать где-то на 10ом уровне вложенности ничего). Соответственно права пользователей не позволяют им не двигать ни удалять ресурсы.
Если Вам уж очень захочется склеить в дерево эти ресурсы, то можно потом на базе той модели, что я описал используя DFS что-то придумать в этом направлении.
Конечно и эта модель не идеальна и иногда пользователи не понимают необходимости создания отдельных ресурсов, но такова жизнь… И поэтому если бы были стандарты или бестпрактиксы на которые можно было бы ссылаться, было значительно проще.
Вообще считаю что NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища (управления файловыми ресурсами, их учета и т.д). Т.е. не хватает целой прослойки ПО которая бы автоматизировала бы эти процессы и стояла уже выше NTFS и обеспечивала бы интерфейс для управления администратору.
Во первых спасибо автору за изложение своего видения этого процесса.
Что хотелось бы отметить и каким опытом поделиться…
1. Никто не отменяет схему AGDLP. И в данном случае если автор говорит что это ресурсные группы, то они должны быть не Global, а Domain Local
2. Привязать имя сетевой папки к имени группы идея очень даже хорошая но не реализуемая в больших средах
3. Есть много вопросов ко вложенным ресурсам
— Траверсы нужно рубить на всей вложенности (и не всегда это второй уровень а может быть и 5ый и 10ый)
— В случае если пользователи которые имеют RW доступ к такой вложенной папке вложенного ресурса (ну возьмем из примера начальника отдела) решит в прекрасный день, что папка Документация должна лежать в другом месте его информационного ресурса, то все прорубленные траверсы до конкретного локейшена не будут иметь смысла, а вот новое местоположение не будет доступно ни по правам (потому что не будет траверса) ни по полному пути (потому что он изменится)
— В случае если информационный ресурс удаляется, то никак не может ограничиваться удалением папки пользователем, хотя бы потому, что надо еще выполнить ряд процедур (удаление из реестра информационных ресурсов, удаление ненужных в ад групп и т.д.). Но в данном случае у пользователей которые имеют права RW могут удалить эту папку потому что они понятия не имеют вложенный это информационный ресурс или обычная папка
Один комментарий по поводу топ менеджеров — например бухгалтера и финансисты работают в соответствии регламентов, которые определяют их деятельность и возможно тоже кто-то хотел бы видеть их работу другой. Но их работа основывается на требованиях законов, документов и т.д. Т.е. они работают по своим стандартам. Пока в ИТ не будет таких же стандартов — на технические решения будет влиять любой менеджер (причем под разных менеджеров можно даже разные решения внедрять по их пожеланию ;-) ). Поэтому я изначально и говорил, что если бы были правила на которые можно было бы ссылаться — было бы проще.
Если вы готовы идти только по своему пути развития своего файлового хранилища и четко понимаете свои проблемы, то я думаю надо тогда и думать:
1. Как автоматизировать задачу прописывания траверсов
2. Как забрать права у пользователей на удаление и перемещения папок вложенных ресурсов и промежуточных папок.
Есть один вопрос. А для чего Вам так нужен траверс для дополнительных ресурсов? Зачем пользователю который по факту не видит всей структуры папок и их содержимого (ведь мы хотим скрыть папки к которым доступа нет у пользователя) должен пробираться например на 5ый уровень вложенности чтобы увидеть папку ДОКУМЕНТАЦИЯ?
На мой взгляд когда пользователь все равно не видит этих папок, то ему удовольствия нет прыгать пять уровней непонятно для чего.
В своей практике я использую немного другую модель. Я не делаю ресурсы вложенными. Я исхожу того, что должно быть четкое правило определение ресурса. Я определяю, что один ресурс — это один набор ACL. Если есть потребность для какой-то части ресурса изменить ACL, то это сигнал к тому, что информационный ресурс надо разделить на два ресурса. Т.е. модель файловых ресурсов с точки зрения ACL получается плоской и нет никаких вложенностей. Все ресурсы всегда находятся на одном уровне вложенности (т.е. всегда размещаются рядом и не надо искать где-то на 10ом уровне вложенности ничего). Соответственно права пользователей не позволяют им не двигать ни удалять ресурсы.
Если Вам уж очень захочется склеить в дерево эти ресурсы, то можно потом на базе той модели, что я описал используя DFS что-то придумать в этом направлении.
Конечно и эта модель не идеальна и иногда пользователи не понимают необходимости создания отдельных ресурсов, но такова жизнь… И поэтому если бы были стандарты или бестпрактиксы на которые можно было бы ссылаться, было значительно проще.
Вообще считаю что NTFS это очень низкоуровневое решение для задач полноценного файлового хранилища (управления файловыми ресурсами, их учета и т.д). Т.е. не хватает целой прослойки ПО которая бы автоматизировала бы эти процессы и стояла уже выше NTFS и обеспечивала бы интерфейс для управления администратору.
Что хотелось бы отметить и каким опытом поделиться…
1. Никто не отменяет схему AGDLP. И в данном случае если автор говорит что это ресурсные группы, то они должны быть не Global, а Domain Local
2. Привязать имя сетевой папки к имени группы идея очень даже хорошая но не реализуемая в больших средах
3. Есть много вопросов ко вложенным ресурсам
— Траверсы нужно рубить на всей вложенности (и не всегда это второй уровень а может быть и 5ый и 10ый)
— В случае если пользователи которые имеют RW доступ к такой вложенной папке вложенного ресурса (ну возьмем из примера начальника отдела) решит в прекрасный день, что папка Документация должна лежать в другом месте его информационного ресурса, то все прорубленные траверсы до конкретного локейшена не будут иметь смысла, а вот новое местоположение не будет доступно ни по правам (потому что не будет траверса) ни по полному пути (потому что он изменится)
— В случае если информационный ресурс удаляется, то никак не может ограничиваться удалением папки пользователем, хотя бы потому, что надо еще выполнить ряд процедур (удаление из реестра информационных ресурсов, удаление ненужных в ад групп и т.д.). Но в данном случае у пользователей которые имеют права RW могут удалить эту папку потому что они понятия не имеют вложенный это информационный ресурс или обычная папка