Файловые серверы - это факт жизни в ИТ, и мне любопытно, существуют ли какие-либо общепринятые методы (я не решаюсь использовать здесь слово «лучший») для создания групп и применения разрешений для управления доступом клиентов к общей папке на файловый сервер.
На моей нынешней работе я унаследовал множество различных способов сделать это, начиная от десятков групп в списках ACL и заканчивая простым размещением отдельных пользователей непосредственно в файловой системе. Моя задача заключалась в том, чтобы навести порядок и придумать какой-то стандартизированный подход к этому во всей компании (большая среда, 150 тысяч сотрудников, 90 тысяч клиентских компьютеров, сотни файловых серверов).
Насколько я понимаю, вам кажется, что вам нужна как минимум одна группа на требуемый уровень доступа для каждого защищенного ресурса. Эта модель, по-видимому, обеспечивает максимальную гибкость, поскольку вам не нужно снова касаться разрешений файловой системы, если вам не нужно поддерживать другой уровень доступа. Обратной стороной является то, что вы создадите больше групп, чем при повторном использовании одной и той же группы на нескольких общих ресурсах.
Вот пример, показывающий, что я имею в виду:
На файловом сервере FILE01 есть общий ресурс под названием «Test Results», и у вас есть люди, которым нужен доступ только для чтения, доступ для чтения-записи и полный контроль. 1 защищенный ресурс * 3 уровня доступа = 3 группы безопасности. В нашей среде AD мы создаем их как универсальные группы, чтобы мы могли легко добавлять пользователей / группы из любого домена в лесу. Поскольку каждая группа однозначно ссылается на общую папку и уровень доступа, имена групп включают в себя эти «ключевые» фрагменты данных, а права доступа:
"FILE01-Test Results-FC" -- Full Control
"FILE01-Test Results-RW" -- Read & Write
"FILE01-Test Results-RO" -- Read Only
Обычно мы также включаем встроенную учетную запись SYSTEM и встроенных администраторов с полным доступом. Любые изменения в отношении того, кто на самом деле получает доступ к этому общему ресурсу, теперь можно обрабатывать с помощью членства в группах, а не прикасаться к ACL (либо путем добавления групп «ролей», представляющих определенные бизнес-роли, такие как менеджеры, технические специалисты, аналитики качества и т. Д., Либо только отдельные лица. пользователей для одноразового доступа).
Два вопроса:
1) Действительно ли это рекомендуемый или допустимый подход для обработки разрешений, или мне не хватает более простого и элегантного решения? Я был бы особенно заинтересован в любых решениях, которые используют наследование, но при этом сохраняют гибкость, так как не нужно повторно настраивать ACL для больших частей файловых систем, когда что-то меняется.
2) Как вы обрабатываете разрешения файлового сервера и структуру групп в своей среде? Бонусные баллы для тех, кто также работает в больших помещениях.
Такой подход неплох. Как правило, никогда не используйте отдельных пользователей для добавления разрешений - используйте группу. Однако группы можно использовать для разных ресурсов. Например, HR может иметь RW доступ к файлам, а MANAGERS - R. Вы также можете настроить перечисление на основе доступа. Взгляните на следующую веб-трансляцию:
Перечисление на основе доступа также может облегчить жизнь. Посмотрите:
Перечисление на основе доступа
ABE может помочь уменьшить количество различных общих ресурсов, которыми вы должны управлять.
Мой подход состоит в том, чтобы не использовать права доступа к файлам на уровне файлов / каталогов; используйте разрешения на уровне файлового ресурса и установите для диска с данными файловой системы всего сервера значение «Полный доступ для всех» (что становится спорным).
С годами (10+) я обнаружил, что разрешения NTFS более сложны и приводят к большему количеству ошибок. Если разрешения установлены неправильно или наследование нарушено, вы раскрываете данные, и их трудно найти и увидеть. Кроме того, вы сталкиваетесь с проблемой перемещения / копирования ... пользователи, перемещающие файлы, также перемещают ACL файла, тогда как copy наследует целевой ACL.
Используйте свои группы чтения / записи одинаково, но для всего файлового ресурса с помощью Comp Mgmt MMC. Не делайте полного ... пользователи будут стрелять в себя с частичным осознанием / лучшими намерениями.
Ваш подход в основном такой же, как и я.
Единственное, что я бы добавил:
1) Я бы добавил к вашей схеме «ролей», оценив то, что им нужно на разных серверах, а не только на одном сервере, вы, вероятно, столкнетесь с выбросами, но моя теория заключается в том, что когда вы сталкиваетесь с ними, создайте другую группу. по моему опыту, когда есть один выброс, их много.
2) Я бы НАСТОЯТЕЛЬНО переоценил необходимость универсальных групп для всего, поскольку вы принимаете с ними удар репликации, поскольку члены и группы внутри универсальной группы реплицируются на серверы глобального каталога, в то время как с локальным доменом и глобальным только группа реплицируется на серверы глобального каталога. Таким образом, если вы вносите изменения в универсальную группу, она запускает репликацию, а в глобальной и локальной для домена - нет.
Ваш метод использования группы ресурсов для каждого уровня доступа правильный. Единственное, что я хотел бы рассмотреть, это использование локальных групп домена для ресурсов. Вам не обязательно использовать универсальные группы, если вы создаете серверные группы ресурсов.
Обратной стороной использования локальных групп домена для ресурсов является то, что в результате вы получаете большее количество групп. Плюс в том, что у вас меньше проблем с репликацией, как заметил Зайфер.
Предлагаемый подход кажется довольно солидным. Одна вещь, на которую следует обратить внимание, - это способ первоначальной настройки общих файловых ресурсов. Рекомендуемая практика - иметь один общий ресурс верхнего уровня, содержащий подпапки, которым вы затем назначаете разрешения группы. NTFS может затем обойти «Traverse Folder / Execute File» в папке верхнего уровня и предоставить доступ к подпапке.
Тогда структура будет выглядеть как \ servername \ sharename \ group-folder, с разрешениями общего доступа, которые нужно установить только для папки «sharename», а фактические разрешения NTFS установлены для папки «group-folder».
Ваш файловый сервер также сможет работать лучше с такой настройкой.
Другие общие вещи, которые я бы сделал, - это соглашение об именах для групп, такое, чтобы имя группы было таким же, как имя папки группы (с добавлением FC / RW / RO, если необходимо), и прикрепить UNC к папке в описании группы (чтобы ваш сценарий входа в систему мог прочитать его и настроить таким образом сопоставление дисков, а также чтобы вам было легче увидеть, какие общие папки применяются к каким группам).
Стандартная практика, которую я использую для файлового сервера Windows со времен Windows 2000 (изложенная в серии статей Марка Минаси «Освоение Windows Server», так что ищите там дополнительную информацию), является использование групп, локальных по отношению к самому файловому серверу, для вложения.
Например, рассмотрим файловый сервер KERMIT в домене MUPPETS.
Скажем, у KERMIT есть несколько общих файловых ресурсов:
\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing
Создайте группы, локальные для KERMIT для доступа, и дайте им разрешения в файловой системе точно так, как вы указали (т.е. одна группа на уровень доступа на общий ресурс)
KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]
Поскольку это локальные группы, вы можете добавлять в них любые другие группы или пользователей - локальные группы домена, глобальные группы, универсальные группы, учетные записи пользователей из любого домена в вашем лесу. Управление правами теперь является локальным для групп файлового сервера, а не для файловой системы или AD.
Это добавляет дополнительный уровень к управлению вашими группами, но дает возможность (скажем) локальным администраторам сайта управлять своими собственными файловыми серверами, не требуя ничего, кроме прав администратора для этого файлового сервера. Если у вас есть федеративная структура филиалов, где каждый тип офиса выполняет свои функции со своими серверами, это может быть реальным преимуществом. Возможно, вам не захочется давать права администратора AD нескольким десяткам администраторов локальных сайтов.
Это также предотвращает загромождение вашего AD большим количеством групп (одна группа на уровень доступа на общий ресурс на сервер может очень быстро складываться) и сводит к минимуму групповую репликацию между GC. Это позволяет вам зарезервировать группы AD для ролей, а не разрешений.
Если ваша среда строго стандартизирована, а все файловые серверы идентичны и реплицированы, то очевидно, что это еще один уровень групп, который вам не нужен. Кроме того, если вы знаете, что вам нужна определенная группа AD, чтобы иметь те же права на общий ресурс, который существует на каждом отдельном файловом сервере, вам понадобится некоторая автоматизация для поддержки этого.
Короче говоря, чем больше ваши файловые серверы отличаются друг от друга, тем больше смысла в использовании локальных групп компьютеров. Чем больше они похожи, тем больше вы хотите использовать систему, которую используете в настоящее время.
Я рассматриваю возможность перехода с NetWare на Windows Server 2008, поэтому в последнее время я много думал об этом. Server 2008 (и в некоторой степени Server 2003R2) имеет несколько очень хороших функций, которые действительно облегчают этот переход. Server 2008 поставляется с перечислением на основе доступа из коробки. Это очень хорошая функция, которая позволяет пользователям видеть только те каталоги, на которые у них есть права. Если у вас есть доля вроде ...
\\ пользователь-дом-SRV \ дома \
Без ABE конечный пользователь увидел бы десятки / сотни / тысячи каталогов. С ABE конечный пользователь увидит только один. То же самое и с долевыми акциями. С ABE вы можете создать единый огромный том для всех каталогов вашего отдела, если хотите, и не спамить своих пользователей каталогами, в которые они не могут попасть. Хотя это не проблема ACL, она в некоторой степени связана, поэтому я поднимаю ее.
Еще одна вещь, в которой Server 2008, похоже, лучше, чем ее более ранние версии, - это наследование ACL. Кажется, что изменение ACL на вершине большого дерева быстрее распространяется на лист.
Благодаря нашему наследию от Netware, у нас есть большое количество групп, названных в зависимости от того, кто в них находится, а некоторые из них названы в соответствии с тем, к чему они предоставляют доступ. Для каталогов с ограниченным доступом мы также используем номенклатуру «RO» «Полная».
У нас есть монолитный «общий» том (все еще в NetWare, но мы планируем сделать его монолитным, когда мы перейдем на Windows), который представляет собой единый общий том для всех 4400 рабочих и содержит более 3,5 миллионов файлов. Все каталоги верхнего уровня - это названия отделов, и каждый отдел регулирует то, что в них происходит. Есть несколько исключений для действительно больших отделов, у которых есть 2-й уровень каталогов с ACL.
На моей последней работе мы даже смогли настроить разрешения, чтобы сотрудники отдела кадров, претендующие на вакансию, не могли видеть данные своих приложений на своем сервере. Для этого потребовались некоторые фильтры прав наследования, аналогичные тегу «блочное наследование» в Windows. Сложнее всего было документировать все это, но работал.
В лучшем случае каждый пользователь должен быть добавлен только в одну группу безопасности для рабочей роли пользователя. Затем роли делегируется доступ там, где это необходимо.
Точно так же доступ к общей папке должен быть предоставлен с использованием групп безопасности «ресурсов», как в вашем примере «FILE01-Test Results-RW». Он будет содержать рабочие роли, роли в отделах или другие соответствующие группы.
Достоинством этого дизайна является то, что вы делегируете доступ для каждой группы (команда, отдел и т. Д.), А не разовый доступ, который может быть трудно отследить. Когда пользователь переходит в другой отдел, вам необходимо очистить весь старый доступ.
Обратной стороной является то, что группы могут использоваться неправильно. Четко разграничивайте, для чего используются группы, чтобы группы ресурсов, назначенные общему ресурсу, не использовались повторно, как если бы они были группами отделов, создавая запутанный беспорядок доступа.