Проблема з роздільною здатністю, Windows IT Pro
Служба Server входить до складу операційних систем на базі Windows NT з того дня, як ці системи з'явилися на світ.
Full Control або Modify
Про небезпеку, пов'язану з використанням дозволу Full Control, знають практично всі фахівці. Коло осіб, яким доводилося розглядати сценарії, де певну небезпеку становлять дозволи Modify, вже не таке широке. Я міг би присвятити не одну сторінку опису погроз, викликаних наданням дозволів Modify та Full Control групам користувачів, але в рамках цієї статті обмежуся лише найсерйознішими небезпеками. Я маю на увазі надання дозволу Delete.
Майже у всіх випадках, які передбачають спільне використання файлів фахівцями з ІТ, така група користувачів отримує дозвіл Modify або Full Control. Так ось, небезпека полягає в тому, що шаблони дозволів Modify і Full Control включають роздільну здатність Delete, яка за замовчуванням застосовується до «даної папки, а також до вкладених у неї папок та файлів». Отримавши такий дозвіл і право його успадкування, користувач подібної групи може видалити будь-який файл або вкладену папку, а також усі файли та вкладені папки. Інакше кажучи, будь-який член команди може вибрати будь-яку папку, натиснути клавішу Delete - і прощайте дані. Таке видалення може бути навмисним або випадковим, але так чи інакше його можна запобігти.
Виділіть час для визначення вимог до папок, доступних для декількох користувачів при виконанні спільних проектів, і не забувайте про те, що дозволи можуть бути використані як на благо, так і на зло. Ви зможете переконатися, що залежно від вимог, що висуваються до папки, дозволу на роботу з якою ви надаєте, проблема вирішенняDelete може бути вирішена кількома способами. Спосіб перший: можна надати всій групі дозвіл Allow::Write, відповідно до якого будь-який член групи зможе створювати та змінювати файли та папки. Потім слід надати дозвіл Delete обмеженій групі користувачів. Спосіб другий: надати групі роздільну здатність Modify, але змінити діапазон дії цієї роздільної здатності, так щоб вона застосовувалася тільки до файлів. При цьому можливість ненавмисного або навмисного видалення файлів усередині папки зберігається, але унеможливлюється рекурсивне видалення вкладених папок у разі ненавмисного видалення.
Delete Subfolders and Files
Ще небезпечніша роздільна здатність Delete Subfolders and Files, запис управління доступом (access control entry, ACE) у шаблоні дозволу Full Controls. Користувач, який має такий дозвіл для роботи з тією чи іншою папкою, може видалити будь-яку вкладену папку або файл у ній, навіть якщо йому було явно надано дозвіл Deny::Delete. Іншими словами, будь-який користувач, який входить до складу групи з роздільною здатністю Full Control стосовно тієї чи іншої папки, може видалити весь її вміст і створити ситуацію відмови в обслуговуванні. А це значно гірше, ніж стандартна роздільна здатність Delete, оскільки роздільна здатність Delete Subfolders and Files перевизначає всі інші дозволи, включаючи явно виражені дозволи Deny. Як тут не згадати про револьвер у руках мавпи.
Щоб уникнути такої ситуації, використовуйте оптимальний метод номер два: виявляйте виняткову обережність при наданні дозволу Full Control. Я рекомендую обмежувати дозволи Full Control областю System. Надайте шаблон роздільної здатності Modify плюс роздільну здатність Change Permissions групам, яким необхідно змінювати дозволи нароботу з папками. До речі, оптимальний метод номер один полягає в наступному: завжди призначайте дозволи не користувачам, а групам. Тепер я переходжу до наступного подразника.
Запис управління доступом Creator Owner
Як вирішити цю прикру проблему? Проаналізуйте дозволи, які повинні мати користувачі папки, що розділяється. Можливо, ви захочете видалити запис керування доступом Creator Owner. Якщо ви призначили членам групи шаблон дозволів Allow::Write так, що вони матимуть можливість змінювати файли своїх колег у папці, що спільно використовується, запис керування доступом Creator Owner вам не знадобиться. Нехай Ден після видалення запису став членом групи і створив новий файл. Цей файл успадковує політику доступу батьківської папки, але жодних явних записів управління доступом для Дена при цьому не створюється. Він може вносити до свого файлу зміни тому, що є членом групи, а коли Ден виходить зі складу групи, його права доступу видаляються. Правда, Ден все ще може як власник повернутися до свого об'єкта і надати собі права. Цією проблемою ми й займемося зараз.
Зміна дозволів
Співробітникам кожної організації доводиться стикатися з проблемами, що виникають через те, що користувачі, діючи навмисне або ненавмисно, змінюють дозволи на звернення до створених ними файлів або папок. У системі Windows передбачено неявну роздільну здатність (WRITE_DAC), що призначається ідентифікатором безпеки security identifier (SID) користувача, який володіє файлом або папкою. Цей дозвіл дає користувачеві можливість змінювати дозволи на звернення до об'єкта навіть у тих ситуаціях, коли без цього немає дозволів Allow::Change. Подібна можливістьздатна викликати загрозу безпеці, оскільки власник файлу або папки може змінити політику доступу, визначену у списку керування доступом до батьківської папки.
До появи системи Windows Vista єдине реальне рішення полягало в тому, щоб змінити блок повідомлень сервера Server Message Block (SMB), тобто дозволу на звернення до спільно використовуваних ресурсів. Як правило, адміністратори як дозволи SMB використовують дозволи Allow::Full Control. Але якщо замість них задіяти обмеження, що накладають більш серйозні, дозволу SMB Allow::Change, користувачі зможуть виконувати будь-які дії, за винятком зміни дозволів.
У системах Vista і Windows Server 2008 проблема, що розглядається, вирішується ще простіше. Розробники цих систем ввели новий спеціальний дозвіл, OWNER RIGHTS, який представляє поточного власника файлу або папки. Дозволи, призначені для цього посвідчення, визначать дозволи для власника та перевизначать неявні права власника, у тому числі право змінювати дозволи. Тому новий оптимальний метод у тому, щоб призначити OWNER RIGHTS::Allow::Modify. Роздільна здатність Modify не має на увазі дозволів Change Permissions, Delete Subfolders and Files і Take Ownership, що входять до складу шаблону дозволів Full Control. Коли на ваших файлових серверах буде встановлена система Server 2008, ця проблема піде в минуле.
Делегування папок, що розділяються
Я дуже зрадів, дізнавшись, що утиліта TweakUI із комплекту PowerToy Windows XP надає можливість делегування цієї функції. Але, на жаль, програма TweakUI не є офіційним компонентом Windows, і Microsoft не підтримує її. Дозвіл створювати ресурс загального користування міститься в двійковому записіреєстрі, і зміна цього запису також не передбачено. Таким чином, як це не прикро, я повинен визнати, що делегувати функцію створення папок спільного доступу членам груп технічної підтримки можна лише одним способом – включивши цих співробітників до складу груп Server Operators або Power Users рядового сервера. Принаймні ви зможете обійтися без надання їм повноважень адміністраторів.
Нарешті, за замовчуванням налаштування для нових папок, що розділяються, в більшості випадків вибрані невдало. Стандартна роздільна здатність Everyone::Allow::Read обмежує права всіх користувачів, включаючи адміністраторів. Ніхто не може отримати доступ до ресурсу на вищому рівні, навіть якщо дозволи NTFS передбачають застосування ліберальніших політик. Усі клієнти, з якими мені доводилося працювати останнім часом, використовують дуже чіткі політики, в яких вказується, що Full Control — це коректний дозвіл на звернення до ресурсів, що розділяються, практично у всіх випадках і що фактична політика доступу визначається дозволами NTFS. Перед нами наочний приклад того, що корпорація Microsoft сховала інструмент занадто глибоко і не дає клієнтам можливості замінити механізми, що застосовуються за замовчуванням, чимось кориснішим.
Подібним чином застосовувані за замовчуванням налаштування кешування дозволяють користувачам вибирати будь-який файл ресурсу для подальшої роботи з ним в автономному режимі. Якщо при цьому не йдеться про папку, що містить виключно файли «тільки для читання», такі налаштування відкривають можливість редагування файлів в автономному режимі, що може викликати конфлікти при синхронізації. З міркувань безпеки я рекомендую розглянути можливість блокування передбаченого за умовчаннямдоступу до файлів в автономному режимі
Щоб змінити параметри кешування за замовчуванням, використовуйте сценарій або командний рядок для ініціалізації та автоматизації ресурсів, що використовуються спільно. Так, команда NET SHARE дозволяє легко створювати загальнодоступні папки; в ній передбачені перемикачі для налаштування дозволів Full Control і відключення автономних файлів для ресурсу, що розділяється:
/GRANT: Everyone, Full та /CACHING: None
Спільне використання файлів для «чайників»
Все, про що я щойно говорив, стосується Windows Vista і Windows Server 2008. На жаль, у системі Windows Server 2008 все залишилося як і раніше. Тому вважайте цей розділ попереднім оглядом проблем, пов'язаних із використанням Windows Server 2008.
Коли я знайомився із системою Windows Server 2008, мене перш за все неприємно вразила команда Share. Нема чого і думати про те, щоб знайти її в контекстному меню вікна Windows Explorer. Нова команда Share зведена до «спільного використання файлів для чайників». При виконанні на екрані відкривається вікно File Sharing (див. екран).
У діалоговому вікні File Sharing користувач може встановлювати дозволи на рівні Reader, Contributor або Co-Owner. У цьому вікні для доступу до ресурсів, що розділяються, і для дозволів NTFS передбачені рівні Read, Change/Modify або Full Control. Подібна реалізація дозволів суперечить письмовим політикам та процедурам практично всіх клієнтів, з якими мені доводилося працювати. Зазвичай відповідно до вимог політик дозволу на доступ до папок, що розділяються, повинні встановлюватися на рівні Full Control, а рівень доступу визначатися дозволами NTFS. Крім того, багато хто з нас навчився спочатку захищати папку, а вжепотім відкривати її для доступу інших користувачів, тому іноді іноді виділяємо якийсь час на підготовку бездоганного списку управління доступом. Але команда, про яку йдеться, надає доступ до папки лише групам, які використовують стандартні шаблони дозволів NTFS Read, Modify або Full Control. Проведіть невеликий експеримент. Захистіть папку таким чином, щоб група користувачів мала дозвіл на запис, а потім спробуйте відкрити її для спільного використання. Ви побачите, що група не отримує дозволів на доступ до ресурсів.
Ця проблема ускладнюється у зв'язку з тим, як саме Microsoft реалізує ролі у діалоговому вікні. У більшості побудованих на ролях моделях безпеки, включаючи розроблені спеціалістами Microsoft моделі загальнодоступних папок SharePoint і xchange, роль Contributor не має права на виконання операції Modify, а роль Editor має таке право. Відмінність між ролями Contributor та Editor полягає в наступному. Contributor може доповнювати ресурс новими матеріалами та змінювати вміст цих матеріалів. На відміну від цієї ролі, користувач Editor може вносити зміни до файлів, що надійшли від будь-якого користувача Contributor. Ми можемо погоджуватися або не погоджуватися з такими визначеннями ролей Editor і Contributor, але не в цьому. Головне, що Microsoft надає собі право тлумачити можливі уявлення про ролі всіх своїх клієнтів. Розробники не дозволяють компаніям вносити зміни до процесів, що відбуваються в діалоговому вікні.
Нарешті, Microsoft ще більше посилює ситуацію, замінюючи старий добрий (і ефективний) інтерфейс Share інструментом, який називаю «засобом спільного використання файлів для чайників». Тепер, щоб дістатися до налаштувань, що дійсно вимагають зміни, користувачуНеобхідно знайти команду Advanced Sharing. І ось я запитую: якщо для того, щоб надати доступ до папки декільком особам, користувач повинен входити в привілейовану групу (таку, як група адміністраторів) і якщо ми, зрештою, маємо справу не з клієнтською, а з серверною операційною системою, невже не можна припустити, що адміністратори знають, що роблять? Навіть у чудовому майстрі Provision a Shared Folder Wizard, реалізованому в диспетчері Server Manager, за замовчуванням застосовуються просто шалені налаштування — такі, як Everyone:: Allow:: Read та Caching=Manual, і їх не можна змінювати відповідно до потреб організації.
Найкраще вирішення цих проблем, що завдають маси клопоту адміністраторам систем Server 2008, полягає у використанні команди Net Share або інших сценаріїв, за допомогою яких можна встановити для папок спільного доступу необхідні параметри. Адже навіть чудова нова оболонка PowerShell не дозволяє встановити для папки, що розділяється, всі налаштування блоку повідомлень сервера Server Message Block. Що тут сказати? Прикро.
Тема не закрита
Проблем, що заважають роботі адміністраторів файлових серверів, а також способів їх вирішення занадто багато для того, щоб їх можна було розглянути в одній статті. Ми ще повертатимемося до цієї теми.
Ден Холм ([email protected]) - директор консалтингової служби Intelliem, яка організовує консультації для підприємств, що впроваджують SharePoint, Office, Windows та Active Directory
Поділіться матеріалом з колегами та друзями