Це рекомендований / дійсний підхід для дозволів файлового сервера?

Файлові сервери - це факт життя в ІТ, і мені цікаво, чи існують загальноприйняті практики (я вагаюся тут використовувати слово "найкраще") для того, як створювати групи та застосовувати дозволи для управління клієнтським доступом до спільної папки на файловий сервер.

На моїй теперішній роботі я закінчив успадковувати безлад різних способів зробити це, починаючи від десятків груп на 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 (або додаючи групи "Ролі", що представляють конкретні ділові ролі, такі як менеджери, технічні працівники, аналітики якості тощо), або просто окремі користувачів для разового доступу).

Два питання:

1) Це насправді рекомендований чи вірний підхід для обробки дозволів чи я пропускаю якесь більш просте, елегантніше рішення? Мене особливо зацікавлять будь-які рішення, які використовують успадкування, але все ж зберігають гнучкість у тому, що не потрібно повторно переглядати великі частини файлових систем ACL, коли все змінюється.

2) Як ви обробляєте дозволи файлового сервера та групову структуру у вашому оточенні? Бонусні бали для тих, хто також працює у великих умовах.

Мій підхід полягає в тому, щоб не використовувати дозволів на файловий / файловий рівень; використовувати дозволи дозволу на загальний доступ до файлів і встановити диск даних для всієї файлової системи сервера на повний контроль для кожного (який стає суперечливим).

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

Використовуйте ваші групи для читання / запису однаково, але для всього спільного використання файлів за допомогою Comp Mgmt MMC. Не виконуйте повноцінного ... користувачі будуть стріляти з частковими знаннями / найкращими намірами.

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

TechNet Webcast: Серія адміністрування Windows Server 2003 (частина 4 з 12): Управління групою (рівень 200)

Перерахування на основі доступу може також полегшити життя.

Перерахування на основі доступу

ABE може допомогти зменшити кількість різних акцій, які вам доведеться вводити.

Ваш підхід в основному такий, як я би підходив до нього.
Єдине, що я хочу додати, це:

1) Я додав би до вашої схеми "ролей", оцінивши, що їм потрібно на серверах, а не лише на одному сервері, напевно, ви збираєтеся зіткнутися з цим, але моя теорія з цим полягає в тому, коли ви натрапите на них, створіть іншу групу. в моєму досвіді там, де є один чужий, багато.

2) Я б СТРУМНО переоцінив потребу в універсальних групах у всьому, коли ви приймаєте з ними звернення до реплікації, оскільки члени та групи всередині групи Universal реплікуються на сервери глобального каталогу, тоді як для Domain Local і Global лише група є копіюється на глобальні сервери каталогів. Отже, якщо ви внесете зміни в універсальну групу, вона починає реплікацію, тоді як для глобальної та доменної локальної це не відбувається.

Ваш метод використання групи ресурсів для кожного рівня доступу є правильним. Єдине, що я вважаю, - це використання локальних груп домену для ресурсів. Не обов’язково використовувати універсальні групи, якщо ви створюєте специфічні для сервера групи ресурсів.

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

Запропонований підхід видається досить твердим. Хоча на що слід звернути увагу, це те, як ви спочатку налаштували файли спільного доступу. Рекомендована практика полягає в тому, щоб мати єдину частку верхнього рівня, що містить підпапки, яким потім призначите групові дозволи. Потім NTFS може обійти "Перемістити папку / Виконати файл" у папці верхнього рівня та надати доступ до підпапки.

Потім структура виглядатиме як \ servername \ sharename \ group-folder, для дозволів на спільне використання потрібно встановити лише папку "sharename", а фактичні дозволи NTFS, встановлені в папці "group-folder".

Ваш файловий сервер також зможе краще працювати з цим налаштуванням.

Загальні речі, які я б робив, - це домовитись про іменування для груп, таким чином, щоб ім'я групи було таким же, як ім'я папки групи (при бажанні додається FC / RW / RO), і приклеювати UNC до папки в описі групи (щоб ваш скрипт входу міг прочитати його назад і встановити відображення диска таким чином, а також, щоб ви могли легше бачити, які спільні папки застосовуються до яких груп).

Стандартна практика, яку я використовую для файлового сервера Windows з Windows 2000 (викладена в серії Mastering 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) мають деякі дуже приємні функції, які дійсно полегшують цей перехід. Сервер 2008 поставляється з переліком на основі доступу з коробки. Це дуже приємна функція, яка дозволяє користувачам бачити лише каталоги, на які вони мають права. Якщо у вас є частка, як ...

\\ user-home-srv \ будинки \

Без ABE кінцевий користувач побачив би десятки / сотні / тисячі каталогів. З ABE кінцевий користувач побачив би лише одне. Те ж саме стосується і спільних акцій. За допомогою ABE ви можете мати єдиний величезний обсяг для всіх ваших відомчих каталогів, якщо хочете, і не розсипати чорт ваших користувачів з каталогами, в які вони не можуть потрапити. Хоча це питання не стосується ACL, воно дещо пов’язане, тому я його вирішую.

Інша справа, що сервер 2008, схоже, робить краще, ніж його попередні версії, це спадкування ACL. Це просто здається швидшим при поширенні вниз до листя, зміна ACL у верхній частині великого дерева.

Завдяки нашій спадщині Netware у нас є велика кількість груп, які названі залежно від того, хто в них є, з декількох з них названих за те, що вони надають доступ. Для каталогів, які мають порядок доступу, ми також використовуємо номенклатуру "RO" "Full".

У нас є монолітний "спільний" об'єм (все ще в NetWare, але ми плануємо мати його монолітним, коли ми переходимо до Windows), який є єдиним спільним томом для всіх 4400 працівників і на ньому понад 3,5 мільйона файлів. Каталоги вищого рівня - це всі назви відділів, і кожен відділ регулює те, що відбувається всередині них. Є кілька винятків для дійсно великих відділів, у яких є каталоги 2-го рівня з ACL.

На моїй останній роботі ми навіть змогли встановити дозволи, щоб співробітники HR, які подавали заявки на роботу, не змогли побачити власні дані заявок на своєму сервері. Для цього знадобилися деякі фільтри спадкових прав, що схоже на тег "блокування спадкування" в Windows. Хитра частина там документувала все це, але це спрацювало .

Найкращий сценарій полягає в тому, щоб кожен користувач був доданий до однієї групи безпеки лише для робочої ролі користувача. Потім роль делегується доступом, де це необхідно.

Так само до спільної папки повинен бути наданий доступ за допомогою груп безпеки "ресурсів", як-от ваш приклад "FILE01-Test Results-RW". Це буде містити робочі ролі, ролі відділу чи інші застосовні групи.

Перевага цієї конструкції полягає в тому, що ви делегуєте доступ на групі (команда, відділ тощо), а не одноразовий доступ, який важко відстежити. Коли користувач переходить в інший відділ, вам потрібно очистити весь старий доступ.

Мінусом є те, що групи можуть бути зловживані. Робіть чіткі розрізнення щодо того, для чого використовуються групи, щоб групи ресурсів, призначені для пайки, не використовувались повторно, як якщо б вони були відомчими групами, створюючи заплутаний безлад доступу.