Комментарии 18
А что делать, если необходимо, например, раздать доступ на ресурсе, в котором 200 папок?
Организовать иерархию папок так, чтобы наследование помоглл решать проблему? Понятно, что кейсы бывают разные, порой структура от вас не зависит, но в таком случае и нужно уточнять: "сейчас будут костыли и велосипеды потому, что у нас тут такое вот наследство ".
что-то мне кажется, что этот скрипт создаёт больше проблем, чем решает — миллионы групп, членством в которых так же нужно управлять.
ИМХО по опыту, отключение наследования в NTFS - зло.
И называть группы доступа по именам самих папок тоже сомнительное решение. Переименует пользователь папку - а вы за ним будете группу переименовывать? Или будете плодить несоответствие?
Мы с коллегами в свое время решили пойти таким путём: договорились с бизнесом, что права раздаются не глубже 3го уровня иерархии и совместно с бизнесом сформировали целевое дерево папок. Потом начался долгий, но неизбежный переход от существовавшей ранее файлопомойки к структурированному виду.
Например, группа для чтения папки Подразделения/Управление малого бизнеса/Отдел продаж называется fs0001_0022_0015_ro и в ее описании в AD указан путь к папке. NTFS-права настроены так, что даже имея доступ на редактирование, пользователи не могут переименовывать папки выше 4го уровня и это делается только через запрос в ИТ. Аналогично - с добавлением новых папок. Другими словами, за глобальный порядок отвечает ИТ, а за порядок в папке 3го уровня и согласование доступов - ответственный за папку от бизнеса.
Ну и квоты ещё прикрутили, т.к. место на файловике не резиновое
Квоты - так себе решение, ибо они еще быстрее заканчиваются чем место на сервере. Угадайте, куда юзер побежит после вашего отказа в повышении квоты, которая скорее всего чётенько зарегламентированна в Вашей Политике ИТ? Правильно - к своему начальнику, который в свою очередь начнет давить через топ-менеджемент уже на ИТ, особенно если мы говорим про Маркетинг-отдел - они-то давить умеют и им абсолютно навалить на то какие там у вас политики и кем они утверждены))). В итоге квотирование превращается в проблему для вас самих же. Зато есть куда более изящное решение - FSRM (разумеется если у вас винда). Вот это штука реально поэффективнее квот - дает возможность запретить загрузку на сервак определенных типов файлов - фильмы, музыка, картинки определенного размера. При внедрении этой штуковины удалось высвободить более 50% места, которое было занято интернами, кухней, шансоном и прочими пляжными фоточками. В итоге после аудита, выпиливания всего личного хлама и последующего внедрения FSRM, на 2ТБ хранилище прекрасно сосуществовало годами под тысячу юзеров и всем всего хватало. Опять же - не забывайте чем больше занято места - тем больше нужно времени и места под бэкап. И да - именование групп и папок должно быть идентичным, иначе это будет каша - просто режьте права на переименование папки на всех уровнях и всё, иначе один тупой юзер переименует папку, в которой работает толпа таких же балбесов. Завтра же они к вам прибегут всем отделом с просьбой вернуть все взад, а тому юзеру даже ничего не будет. На файл сервере дожно работать основное правило ИТ - то что явно не разрешено - должно быть запрещено, иначе это будет хаос. Есть еще другой момент - архивация. Вы когда нибудь задумывались, с какой долей вероятности юзеру могут потребоваться файлы, скажем 3-4 летней давности? Правильно - с долей, близкой к 0. Поэтому, периодически можно архивировать всё содержимое сервера с удалением файлов, которые старше, ну скажем лет 5-ти. Архив этот ложить на простой хард и в сейф - тоже высвобождает немало места . Немножко рисково, затратно по времени, зато прекрасно работает для шараг, жадных на апгрейд простого файл-сервака.
Квоты - это и есть одна из возможностей FSRM. Если Вы так топите за FSRM, должны быть в курсе. И, к слову, есть мягкие квоты, которые позволяют просто видеть превышение, не накладывая запрет на запись в папку. А потом на основании созданных отчётов можно показать руководству, кто из отделов ест много места на файловике и при желании даже посчитать, во сколько это обходится компании.
А то, о чем Вы говорите, - это, судя по всему, другой компонент FSRM, Управление классификациями
Я не особо помню, что там является компонентом чего. Было давно, возможно даже на 2003-й винде - сперва были жёсткие квоты с постоянными жалобами на токсичность админов. Потом был поставлен ФСРМ, упразднены квоты, и "жизнь наладилась". Кстати и сетевая нагрузка на сервак упала заметно, т.к. юзеры перестали крутить свой медиа-контент. По поводу ваших отчетов - руководству абсолютно не интересно кто там и на сколько превысил квоту. Руководству интересены отчеты о прибыли/затратах, но никак не статистика файлхранилища. Руководство перед ИТ обычно ставит четкую и ясную задачу - обеспечить работоспособность структуры, так чтобы она (структура) удовлетворяла потребностям компании. Цена вашему отчету - 2 жестких диска - даже для малого ентерпрайса это мелочь - вам одобрят расширение хранилища, не сомневайтесь. И скорее попросят подобные отчеты больше не приносить.
Есть такое понятие, как стоимость хранения информации.
даже для малого ентерпрайса
Судя по этой фразе, у вас был SOHO-вариант инфраструктуры. А если брать "кровавый энтерпрайз", где нормальное резервирование, бэкапы и объемы данных далеко не 1ТБ на всю компанию, то стоимость эта будет далека от стоимости 2х жёстких дисков. Так что всё относительно.
Если вы читали мой предыдущий комент, то 1000 юзеров это уже точно далеко не соха, а такой крепкий средний энтерпрайс. В "кровавом" ентрепрайсе совсем другой CAPEX крутится - там отличие на 4-5 порядков по сравнению с сохой. Вам не то что 2 два харда не зажмут, вам даже одобрят пару новых СХД с конфой, которую вы попросите. Лишь бы работало, без всяких даун-таймов, вызванных закончившейся квотой. Там на Файловое хранилище выделяется отдельный человек а может и подразделение, при условии что CIO адекватный, а не был поставлен чтобы экономить и распиливать оптимизировать.
А что делать, если приходит отдел продаж через руководство, и говорит, что у них есть папка "Проект Х" в отделе, и к нему надо дать доступ отделу У из другого подразделения для совместной работы?
А потом приходит Бухгалтерия и говорит, что вот у нас проходит аудит, и нам надо поздравление/управление/бухгалтерия/аудит/основные средства/филиал 1, филиал 2, филиал 3
Причём, каждый филиал должен видеть только свои данные, а бухгалтерия все вместе
И кроме основных средств такую же структуру аудита для другого чего-нибудь.
Как вы такое разруливаете?
Насущный вопрос, и на мой взгляд здесь применим принцип того же Teams от Microsoft. Для каждой отдельной задачи - отдельная Команда (Папка верхнего уровня).
Если все таки речь про обычный файловый сервер, как вариант, еще использование junction link для папок. Папка хранится в одном месте, а в другом на нее жесткая ссылка. Если папки разнесены, то использовать DFS.
ИМХО по опыту, отключение наследования в NTFS — зло.
По моему опыту — не зло не особое: совсем нетрудно написать скрипт (точнее, строчку команды в PS), которая выведет список всех папок с отключенным наследованием внутри указанной.
Структура групп и папок это часть дела. А как сделать Делегирование по управлению и согласованию получения доступа и чтобы не айти отдел кликал, а сам пользователь. Мы например прикрутили IDM Midpoint evolveum.
Недавно решал такую же задачу. Но на мой взгляд источником подобной информации был AD, в котором по средствам объектов типа "Общая Папка/Shared folder" создал нужную структуру каталогов с указанием пути. После чего скрипт пробегает по АД, создаёт папки в указанном месте, создает группы и назначает группы на папки. Папки и группы не ниже 2-3его уровня. Каждая новая задача, функция, отдел - новая папка в корне. А по поводу прав, только две группы RW и RO. На папки (и на уровне папки) где, кроме админа ничего не должен менять для всех стоит RO, на конечных папках RW. Бонусом - обнаружил что с помощью файлов desktop.ini можно для папки задавать локализованное имя. Т.е. все папки изначально на англ языке и без пробелов (это еще с cmd пошло, чтобы не плодить лишние кавычки и не переживать, за обработку.) А в дескопт.ини прописано название папки в человеческом виде, как и будет отображаться у пользователя.
что делать, когда появляются спец запросы? Типа "чтобы могли копировать файлы в папку, но не могли изменять"
Спец. запросы это всегда боль. Если такой спец. запрос единичный - делать руками. Если постоянные - править логику работы скрипта. На мой взгляд.
Помнится, на одной из предыдущих работ была папка для фотографий. Туда сотрудники (в основном маркетинг) выкладывали снимки с корпоративов. Систематически некоторые сотрудники других отделов удаляли добавленные маркетологами совместные фото (например, если сами там плохо получились), а другие потом жаловались, что пропали бесценные фото с их участием. Мы тогда настроили права так, что все пользователи могли смотреть всё и добавлять новое, но удалять могли только то, что добавили сами (те файлы и папки, где они владельцы)
Ну в 2011 писал для этого winform приложуху. Потому что структура папок была вывернута наизнанку, по отношению к структуре организации. Т.е чем глубже в папки, тем меньше людей имело доступ.
У кого нет прав не видел папок. Или бывало что надо дать права только на первый уровень и четвёртый, без доступа на промежуточные папки.
Автоматическая раздача прав на файловом сервере