Это рекомендуемый / действительный подход для разрешений файлового сервера?

Файловые серверы являются фактом жизни в ИТ, и мне любопытно, есть ли какие-либо общепринятые практики (я не решаюсь использовать слово «лучший» здесь) для того, как вы создаете группы и применяете разрешения для управления доступом клиентов к общей папке в файловый сервер.

На моей нынешней работе я унаследовал довольно много разных способов сделать это - от десятков групп в ACL-списках до размещения отдельных пользователей непосредственно в файловой системе. Моя задача состояла в том, чтобы навести порядок и придумать какой-то стандартизированный способ решения этой проблемы во всей компании (большая среда, 150 тыс. Сотрудников, 90 тыс. Клиентских компьютеров, 100 файловых серверов).

Из моего понимания проблемы кажется, что вам как минимум нужна одна группа на требуемый уровень доступа на защищенный ресурс. Эта модель, по-видимому, обеспечивает наибольшую гибкость, поскольку вам не нужно снова касаться разрешений файловой системы, если вам не требуется поддержка другого уровня доступа. Недостатком является то, что вы создадите больше групп, чем при повторном использовании одной и той же группы для нескольких общих ресурсов.

Вот пример, показывающий, что я имею в виду:

На файловом сервере с именем FILE01 имеется общий ресурс «Результаты теста», и у вас есть люди, которым необходим доступ только для чтения, доступ для чтения и записи и полный контроль. 1 защищенный ресурс * 3 уровня доступа = 3 группы безопасности. В нашей среде AD мы создаем их как универсальные группы, чтобы мы могли легко добавлять пользователей / группы из любого домена в лесу. Поскольку каждая группа однозначно ссылается на общую папку и уровень доступа, имена групп включают в себя эти «ключевые» фрагменты данных, и поэтому разрешения:

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

Как правило, мы также включаем встроенную учетную запись SYSTEM и встроенных администраторов с полным доступом. Любые изменения в том, кто на самом деле получает какой доступ к этому общему ресурсу, теперь можно обрабатывать, используя членство в группах, вместо того, чтобы прикасаться к списку ACL (добавляя группы «Роли», представляющие конкретные бизнес-роли, такие как менеджеры, технические специалисты, аналитики QA и т. Д., Или просто отдельные лица). пользователи для одноразового доступа).

Два вопроса:

1) Это действительно рекомендуемый или действительный подход для обработки разрешений или я упускаю какое-то более простое, более элегантное решение? Я был бы особенно заинтересован в любых решениях, которые используют наследование, но все еще сохраняют гибкость в том, что нет необходимости переопределять ACL большие части файловых систем, когда что-то меняется.

2) Как вы обрабатываете разрешения файлового сервера и структуру группы в вашей среде? Бонусные баллы для тех, кто также работает в больших средах.

Мой подход заключается в том, чтобы не использовать файловые / каталоговые права доступа; используйте разрешения уровня общего файлового ресурса и установите диск данных файловой системы всего сервера в режим «Полный доступ» (который становится спорным).

За годы (10+) я обнаружил, что разрешения NTFS более сложны и приводят к большему количеству ошибок. Если права доступа установлены неправильно или наследование нарушено, вы открываете данные, и их сложно найти и увидеть. Кроме того, вы сталкиваетесь с проблемой перемещения / копирования ... пользователи, перемещающие файлы, также перемещают ACL файла, тогда как копия наследует целевой ACL.

Используйте те же группы чтения / записи, но на общем файловом ресурсе, используя Comp Mgmt MMC. Не делайте полной ... пользователи будут снимать себя с частичным знанием / благими намерениями.

Такой подход не плохой. Как правило, никогда не используйте отдельных пользователей для добавления разрешений - используйте группу. Однако группы могут использоваться в разных ресурсах. Например, HR может иметь доступ RW к файлам, в то время как MANAGERS может иметь R. Вы также можете настроить перечисление на основе доступа. Посмотрите на следующую веб-трансляцию:

Веб-трансляция TechNet. Серия администрирования Windows Server 2003 (часть 4 из 12): Управление группами (уровень 200)

Перечисление на основе доступа также может упростить жизнь.

Перечисление на основе доступа

ABE может помочь уменьшить количество различных общих ресурсов, которыми вы должны управлять.

Ваш подход в основном так, как я бы подошел.
Единственное, что я хотел бы добавить, это:

1) Я бы добавил к вашей схеме «ролей», оценивая то, что им нужно для разных серверов, а не только на одном сервере, с которым вы, вероятно, столкнетесь с выбросами, но моя теория с ними заключается в том, что когда вы сталкиваетесь с ними, создайте другую группу. в моем опыте, где есть один выброс, есть много.

2) Я бы НАСТОЯТЕЛЬНО переоценил необходимость универсальных групп для всего, так как вы выполняете репликацию с ними, поскольку члены и группы внутри универсальной группы реплицируются на серверы глобального каталога, в то время как с локальным и глобальным доменом только группа является реплицируется на серверы глобального каталога. Таким образом, если вы вносите изменения в универсальную группу, она запускает репликацию, в то время как для глобальных и доменных локальных это не так.

Ваш метод использования группы ресурсов для каждого уровня доступа правильный. Единственное, что я хотел бы рассмотреть, - это использовать локальные группы домена для ресурсов. Вам не обязательно использовать универсальные группы, если вы создаете серверные группы ресурсов.

Недостатком использования доменных локальных групп для ресурсов является то, что в итоге вы получаете больше общих групп. Плюс в том, что у вас меньше проблем с репликацией, как заметил Зайфер.

Предложенный подход кажется довольно солидным. Однако стоит обратить внимание на то, как вы изначально настраивали общие файловые ресурсы. Рекомендуется использовать один общий ресурс верхнего уровня, содержащий подпапки, которым вы затем назначаете разрешения для группы. Затем NTFS может обойти «Папка перемещения / Выполнить файл» в папке верхнего уровня и предоставить доступ к подпапке.

Структура будет выглядеть как \ 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». Он будет содержать рабочие должности, роли отделов или другие применимые группы.

Преимущество этой схемы заключается в том, что вы делегируете доступ для каждой группы (группы, отдела и т. Д.), А не одноразовый доступ, который может быть сложно отследить. Когда пользователь переходит в другой отдел, вам нужно очистить весь старый доступ.

Недостатком является то, что группы могут быть использованы неправильно. Проведите четкое различие в отношении того, для чего используются группы, чтобы группы ресурсов, назначенные для общего ресурса, не использовались повторно, как если бы они были группами отделов, создавая запутанный беспорядок доступа.