1. Секрети системи NTFS Управління доступом до файлів і папок в системі Windows - процес непростий;...
2. Секрети системи NTFS
3. Секрети системи NTFS

Секрети системи NTFS

Управління доступом до файлів і папок в системі Windows - процес непростий; для забезпечення безпеки ресурсів необхідний ефективний механізм захисту. Саме такий механізм реалізований в моделі безпеки NTFS, яка дозволяє адміністратору жорстко контролювати дії користувачів, які здійснюють читання або запис в файлах системи і так чи інакше працюють з ними.

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

1. обмежується п'ятьма стандартними дозволами на звернення до файлів

Система NTFS дозволяє надавати 14 особливих дозволів, які точно визначають, яким чином користувач може звертатися до того чи іншого файлу. Ці дозволи досить деталізовані, тому, не вдаючись у подробиці, відзначимо, що в NTFS 14 дозволів зводяться до п'яти стандартним - або видовим - дозволами, як показано в таблиці. Наприклад, стандартні дозволи дають можливість надати користувачеві повний контроль (Full Control) над файлом, замість того щоб надавати йому окремо кожне з 14 особливих дозволів.

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

У вікні командного рядка добре видно, в чому полягає відмінність між записом в файл і приєднанням даних. Щоб записати дані в файл, потрібно ввести наступну команду:

C:> echo «new text»> test.txt

Якщо в програмі Notepad відкрити файл test.txt, ви побачите, що він містить один рядок - «new text».

Тепер спробуємо приєднати дані до файлу. Для цього можна використовувати наступну команду:

C:> echo «Line 2» >> test.txt

Тепер, якщо ви відкриєте файл test.txt в додатку Notepad, то побачите, що він містить два рядки:

«New text»

«Line 2»

На жаль, такі деталізовані дозволу часто неможливо використовувати. Зараз я поясню чому. Система NTFS «розуміє» різницю між записом і приєднанням даних, так що у вас може виникнути бажання встановити такий дозвіл, яке дозволяє приєднувати дані, але відмовляє в доступі з правом запису. Отже, встановимо дозвіл на доступ до файлу test.txt з наданням прав на виконання будь-яких операцій, крім запису даних (Write Data), як показано на екрані 1.

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

C:> echo «Line 3» >> test.txt

вам буде відмовлено в доступі. Більш того, тепер ви не зможете ні записувати дані в файл, ні приєднувати дані до файлу з командного рядка. Але і це ще не все. Якщо спробувати домогтися зворотного ефекту і дати дозвіл на запис даних (Write Data) з одночасною забороною на приєднання даних (Append Data), побачимо, що і ця комбінація не дає результату. Інакше кажучи, якщо ви блокуєте одну операцію, одночасно блокується і друга.

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

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

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

Отже, хоча система NTFS дозволяє надавати досить деталізовані дозволу, наша здатність реалізовувати ці дозволи обмежується тим, чи були враховані відповідні деталі розробниками програмного забезпечення. Ми можемо виявляти високу пильність і встановлювати досить деталізовані дозволу на доступ до файлів, але зазвичай наше прагнення враховувати більше обставин, ніж дозволяють п'ять стандартних дозволів, обертається марною тратою часу.

2. Пам'ятайте про двох винятки з порядку спадкування дозволів

Модель спадкування, яка використовується системою NTFS для управління доступом, грає важливу роль у визначенні того, хто має право доступу до того чи іншого файлу. Щоб визначитися з дозволами, Windows повинна звіритися зі списком управління доступом, що належать до даного файлу. Кожен файл і папка мають власний список управління доступом, де надається або блокується доступ для конкретних користувачів або груп. Але цей об'єкт може до того ж успадковувати дозволу від своєї батьківської папки або від будь-якої комбінації папок вищого рівня. Всі ці дозволи можуть конфліктувати один з одним - один список керування доступом може дозволяти користувачеві доступ до файлу, тоді як інший може явно відмовляти йому в доступі. Більш того, користувач може бути членом декількох груп, які мають різні дозволи.

Для вирішення проблеми конфліктуючих списків управління доступом в Windows використовується базовий набір правил:

• на будь-якому даному рівні дозволу від декількох груп об'єднуються;

• на будь-якому даному рівні негативні дозволу (заборони) мають пріоритет над позитивними;

• дозволу, надані об'єкту безпосередньо, мають пріоритет над успадкованими дозволами;

• дозволу, успадковані від «близьких родичів», мають пріоритет над дозволами, успадкованими від «далеких родичів».

Будь-який об'єкт може бути захищений від успадкування дозволів від батьківських папок.

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

Об'єкт можна захистити від процесу успадкування. Для цього в діалоговому вікні Advanced Security Settings потрібно перейти на вкладку Permissions і зняти прапорець Allow inheritable permissions from the parent to propagate to this object and all child objects, як показано на екрані 2. Якщо ви виконаєте цю операцію, настройки батьківської папки вже не будуть впливати на параметри безпеки поточного файлу або папки або будь-яких інших файлів або папок, розташованих нижче в ієрархічній структурі - майже у всіх випадках.

Два маловідомих виключення в цій системі захисту від успадкування дозволів можуть призвести до плутанини. Перше полягає в тому, що відмова в наданні доступу до файлу з правом читання (Read Attributes) недійсний, якщо батьківська папка дозволяє складати список каталогу. Якщо ви явно відмовляєте користувачам в доступі до файлу з правом читання, будь-який користувач, який має право складання списку вмісту каталогу, може також переглядати атрибути будь-якого файлу в даному каталозі. Очевидно, що це виняток порушує правила 2 і 3 - воно дозволяє записи «Дозволити» отримувати пріоритет над записом «Відмовити» і дає можливість дозволами батьківської папки отримувати пріоритет над обмеженнями, які накладені безпосередньо на об'єкт. Крім того, це виняток порушує правила 4 і 5, тому що, навіть якщо ви явно захистіть файл від успадкування дозволів, знявши прапорець Allow inheritable permissions from the parent to propagate to this object, батьківська папка буде як і раніше впливати на вирішення об'єкта.

Другий виняток полягає в тому, що відмова в дозволі на видалення (Delete Attributes) стосовно до файлу або папці не діє, якщо батьківська папка має дозвіл на видалення підпапок і файлів (Delete Subfolders and Files). Оскільки за замовчуванням майже всі папки мають дозвіл на видалення підпапок і файлів, відмова в дозволі на видалення файлу рідко матиме ефект. Цей виняток може призвести до плутанини, бо ви, наприклад, можете позбавити когось права на видалення того чи іншого файлу, а потім виявиться, що ця людина проте має право на його видалення. Це виключення з декількох правил спадкування, і знову-таки воно зберігає силу, навіть якщо ви явно захистіть файл від успадкування дозволів з боку його батьківської папки.

Але цим складності не вичерпуються. Можливо, ви подумали, що, якщо при наданні дозволу на видалення підпапок і файлів для деякої папки користувачі можуть видаляти підпапки та файли, з цього випливає, що при відмові в такому дозволі користувачі не зможуть видаляти підпапки та файли. Зовсім ні. Відмова в дозволі на видалення підпапок і файлів для тієї чи іншої папки, по суті, означає надання права застосовувати дозвіл на видалення до будь-яких дочірніх об'єктів. Для виключення можливості видалення файлів можна використовувати один з двох дозволів - дозвіл на видалення підпапок і файлів або дозвіл на видалення. Захист файлу від видалення - це процес, що складається з двох етапів. Спочатку потрібно відмовити в праві на видалення стосовно файлу, а потім - в праві видаляти підпапки та файли стосовно батьківської папки.

3. Дозвіл на виконання файлу може виявитися корисним

Вище я говорив про те, що адміністраторам не варто витрачати сили на встановлення дозволів з високим рівнем деталізації, але з цього правила, на мій погляд, є один виняток - це дозвіл на виконання файлу (Execute File). Одне зі стандартних дозволів формулюється як Read and Execute, але в дійсності для виконання файлу користувачеві не потрібен доступ з правом читання. У більшості випадків для виконання файлу користувачеві потрібен тільки доступ з правом Execute and Read Attributes. Більш того, зазвичай користувачеві не потрібно навіть надавати доступ з правом Read Attributes, тому що він автоматично отримає це право від батьківської папки, про що я вже згадував.

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

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

При наданні дозволу на виконання файлу деталізований контроль може бути корисним. Не будемо забувати, однак, що для виконання сценаріїв і командних файлів необхідно дотримання тих же умов, тільки, що називається, з точністю до навпаки: користувачеві повинно бути надано право на читання, а дозвіл на виконання файлу не потрібно. Цікаво відзначити, що в разі відмови в дозволі на виконання файлу стосовно компоненту ActiveX DLL або OLE Custom Control (OCX) користувачі позбавляються можливості звернення до файлу regsvr32.exe з метою реєстрації цього компонента.

4. Деякі дозволу не настільки корисні, як інші

Деякі дозволу на маніпуляції з файлами менш корисні, ніж інші, просто тому, що такі дозволи перевизначаються іншими прийнятими за замовчуванням системними привілеями. Неможливо, наприклад, відмовити у наданні дозволу приймати об'єкти у володіння (Take Ownership) тим користувачам, які мають системну привілей на відновлення файлів і каталогів (остання за замовчуванням надається адміністраторам і операторам резервного копіювання, оскільки ці користувачі мають системну привілей брати до володіння файли або інші об'єкти). Ви можете позбавити цієї системної привілеї адміністраторів, але, будучи адміністраторами, вони, в свою чергу, можуть відновити її.

По суті, дозвіл брати до володіння має мало сенсу. Справа в тому, що за замовчуванням брати до володіння файли можуть тільки члени групи адміністраторів або операторів резервного копіювання, і всякий користувач, що входить до складу однієї з цих груп, вже має системну привілей брати до володіння файли або інші об'єкти. Єдина ситуація, в якій слід було б застосовувати цей дозвіл, - це випадок, коли користувач або група не входить до складу групи адміністраторів, не має системної привілеї відновлювати файли і каталоги, але має право брати до володіння файли або інші об'єкти і ви хочете позбавити цього користувача або групу можливості прийняти у володіння конкретний набір файлів. Тільки в такому випадку дозвіл брати до володіння буде функціонувати, як очікується; в інших ситуаціях з ним просто не варто зв'язуватися.

Спеціальні дозволи на читання (Read Permissions) і на внесення змін (Change Permissions) незастосовні до власника файлу, навіть якщо адміністратор явно відмовить йому в цих дозволах. Отже, згадані дозволу незастосовні також до будь-якому користувачеві, що користується правом приймати у володіння файли або інші об'єкти. Якщо ви хочете відмовити комусь в дозволі на зчитування даних або на внесення змін, вам доведеться відмовити цьому користувачу в можливості приймати об'єкти у володіння.

Відзначимо, що хоча в дозволах на читання і в дозволах на внесення змін не міститься явно вираженого дозволу або обмеження на доступ до налаштувань аудиту (тобто до системних списками ACL-SACL), в більшості механізмів перегляду, таких як вкладка Security в діалоговому вікні програми Windows Explorer, не відображається список SACL, якщо ці дозволи (тобто дискреційні списки ACL-SACL) не надані.

Нарешті, вам, ймовірно, немає потреби встановлювати дозволу на переміщення по каталогам (Traverse Folder), оскільки за замовчуванням кожен користувач системи має привілей обходу перевірки переміщення (Bypass Traverse Checking), яка, по суті справи, зводить нанівець це дозвіл. Більш того, фахівці Microsoft давно вже рекомендують не здійснювати перевірок переміщення, бо відомо, що в результаті виникають проблеми з додатками, які не забезпечують коректної обробки помилок навігації по каталогам.

5. Дозволи на спільний доступ до ресурсів доповнюють, але не замінюють дозволів NTFS

Коли ви надаєте дозволу на спільне використання файлу, ці дозволи діють незалежно від дозволів NTFS на доступ до файлів і папок, але в поєднанні з даними дозволами. Система Windows розглядає обидва набору дозволів і використовує дозволу з тієї групи, де надається найменший обсяг прав.

Дозволи NTFS мають більший пріоритет, ніж дозволу на спільний доступ до ресурсів. Якщо останні й управляють доступом до файлів, розміщених на мережевих ресурсах, то вони не можуть перешкодити користувачам звернутися до цих файлів безпосередньо в системі або через службу терміналів. Тому я рекомендую читачам при регулюванні доступу завжди покладатися на вирішення NTFS і використовувати дозволу на спільний доступ до файлів тільки для того, щоб накласти додаткові обмеження на права користувачів мережі.

Крім того, важливо відзначити, що дозволу на доступ до кожного спільно використовуваному ресурсу стосуються лише даного ресурсу - вони не успадковуються і не поширюються на окремо збережені спільно використовувані ресурси, навіть якщо останні розташовуються на більш низьких поверхах тієї ж структури фізичного каталогу. Нехай, наприклад, у вас є призначений для всіх користувачів розділяється ресурс, розташований в каталозі D: users. Всі користувачі можуть звертатися до цього ресурсу і до всіх об'єктів, розташованим на більш низьких рівнях структури. Тепер уявіть собі, що ви створюєте призначений тільки для адміністраторів ресурс за адресою D: usersadmin. Другий ресурс, хоча він і є вкладеним в перший, не має з ним ніякого зв'язку. Навіть якщо ви відмовите звичайним користувачам в доступі до ресурсу D: usersadmin, вони зможуть звернутися до цієї папки, відкривши каталог D: users і перейшовши в папку admin. Для блокування доступу користувачів до каталогу admin доведеться призначити відповідні дозволи NTFS. Щоб такі ситуації не виникали, в більшості випадків краще уникати вкладених структур спільно використовуваних ресурсів.

6. Прив'язуйте дозволу до вбудованим групам

При призначенні дозволів на звернення до файлів і папок слід використовувати великий набір вбудованих груп, до яких Windows автоматично зараховує користувачів в залежності від того, як вони реєструються в системі. Існує, наприклад, група віддалених користувачів настільних систем (Remote Desktop Users). Можна встановлювати досить деталізовані дозволу NTFS в залежності від типу реєстрації. Так, у вас може виникнути необхідність надати доступ до певних конфіденційних файлів тільки адміністратору або користувачу, який входить в систему з локальної консолі. Це можна зробити, надавши доступ тільки групам Administrators і Interactive Logon Users. Можна також обмежити доступ до певних файлів, так щоб вони були доступні лише для облікових записів, зареєстрованих як служби. Повний список вбудованих учасників безпеки наведено в статті «Well-known security identifiers in Windows operating systems», опублікованої за адресою http://support.microsoft.com/kb/243330 .

(Додаткові відомості про вбудованих учасників безпеки містяться також в статті «Вбудовані учасники системи безпеки» , Опублікованій в Windows ITPro / RE № 1 за 2006 р - Прим. ред.).

7. Проявляйте обережність при використанні групи Everyone

Прийшов час дати остання порада: проявляйте обережність при роботі з групою Everyone. У версіях Windows, випущених до виходу в світ Windows XP, в групу Everyone за замовчуванням включалися анонімні користувачі, тому адміністраторам завжди радили не надавати права доступу членам цієї групи. Але в версіях Windows XP, Windows Server 2003 і Windows Vista анонімні користувачі за замовчуванням не входять в групу Everyone, так що в залежності від конкретних дозволів відмову в доступі членам групи Everyone не означає відмови анонімним користувачам. Найбезпечніший спосіб заблокувати доступ до ресурсів з боку анонімних і інших небажаних користувачів полягає не в тому, щоб відмовляти їм у праві доступу, а в тому, щоб надавати це право тільки конкретним користувачам і групам.

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

(Додаткову інформацію про дозволи NTFS і дозволи на звернення до ресурсів можна знайти в статті «Путівник по дозволам файлової системи» за адресою http://www.osp.ru/win2000/2007/06/4367585/ - Прим. ред.).

Марк Барнетт ( [email protected] ) - незалежний консультант з безпеки і автор, який спеціалізується на проблемах безпеки Windows. Володар сертифікату IIS MVP

Секрети системи NTFS

Управління доступом до файлів і папок в системі Windows - процес непростий; для забезпечення безпеки ресурсів необхідний ефективний механізм захисту. Саме такий механізм реалізований в моделі безпеки NTFS, яка дозволяє адміністратору жорстко контролювати дії користувачів, які здійснюють читання або запис в файлах системи і так чи інакше працюють з ними.

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

1. обмежується п'ятьма стандартними дозволами на звернення до файлів

Система NTFS дозволяє надавати 14 особливих дозволів, які точно визначають, яким чином користувач може звертатися до того чи іншого файлу. Ці дозволи досить деталізовані, тому, не вдаючись у подробиці, відзначимо, що в NTFS 14 дозволів зводяться до п'яти стандартним - або видовим - дозволами, як показано в таблиці. Наприклад, стандартні дозволи дають можливість надати користувачеві повний контроль (Full Control) над файлом, замість того щоб надавати йому окремо кожне з 14 особливих дозволів.

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

У вікні командного рядка добре видно, в чому полягає відмінність між записом в файл і приєднанням даних. Щоб записати дані в файл, потрібно ввести наступну команду:

C:> echo «new text»> test.txt

Якщо в програмі Notepad відкрити файл test.txt, ви побачите, що він містить один рядок - «new text».

Тепер спробуємо приєднати дані до файлу. Для цього можна використовувати наступну команду:

C:> echo «Line 2» >> test.txt

Тепер, якщо ви відкриєте файл test.txt в додатку Notepad, то побачите, що він містить два рядки:

«New text»

«Line 2»

На жаль, такі деталізовані дозволу часто неможливо використовувати. Зараз я поясню чому. Система NTFS «розуміє» різницю між записом і приєднанням даних, так що у вас може виникнути бажання встановити такий дозвіл, яке дозволяє приєднувати дані, але відмовляє в доступі з правом запису. Отже, встановимо дозвіл на доступ до файлу test.txt з наданням прав на виконання будь-яких операцій, крім запису даних (Write Data), як показано на екрані 1.

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

C:> echo «Line 3» >> test.txt

вам буде відмовлено в доступі. Більш того, тепер ви не зможете ні записувати дані в файл, ні приєднувати дані до файлу з командного рядка. Але і це ще не все. Якщо спробувати домогтися зворотного ефекту і дати дозвіл на запис даних (Write Data) з одночасною забороною на приєднання даних (Append Data), побачимо, що і ця комбінація не дає результату. Інакше кажучи, якщо ви блокуєте одну операцію, одночасно блокується і друга.

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

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

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

Отже, хоча система NTFS дозволяє надавати досить деталізовані дозволу, наша здатність реалізовувати ці дозволи обмежується тим, чи були враховані відповідні деталі розробниками програмного забезпечення. Ми можемо виявляти високу пильність і встановлювати досить деталізовані дозволу на доступ до файлів, але зазвичай наше прагнення враховувати більше обставин, ніж дозволяють п'ять стандартних дозволів, обертається марною тратою часу.

2. Пам'ятайте про двох винятки з порядку спадкування дозволів

Модель спадкування, яка використовується системою NTFS для управління доступом, грає важливу роль у визначенні того, хто має право доступу до того чи іншого файлу. Щоб визначитися з дозволами, Windows повинна звіритися зі списком управління доступом, що належать до даного файлу. Кожен файл і папка мають власний список управління доступом, де надається або блокується доступ для конкретних користувачів або груп. Але цей об'єкт може до того ж успадковувати дозволу від своєї батьківської папки або від будь-якої комбінації папок вищого рівня. Всі ці дозволи можуть конфліктувати один з одним - один список керування доступом може дозволяти користувачеві доступ до файлу, тоді як інший може явно відмовляти йому в доступі. Більш того, користувач може бути членом декількох груп, які мають різні дозволи.

Для вирішення проблеми конфліктуючих списків управління доступом в Windows використовується базовий набір правил:

• на будь-якому даному рівні дозволу від декількох груп об'єднуються;

• на будь-якому даному рівні негативні дозволу (заборони) мають пріоритет над позитивними;

• дозволу, надані об'єкту безпосередньо, мають пріоритет над успадкованими дозволами;

• дозволу, успадковані від «близьких родичів», мають пріоритет над дозволами, успадкованими від «далеких родичів».

Будь-який об'єкт може бути захищений від успадкування дозволів від батьківських папок.

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

Об'єкт можна захистити від процесу успадкування. Для цього в діалоговому вікні Advanced Security Settings потрібно перейти на вкладку Permissions і зняти прапорець Allow inheritable permissions from the parent to propagate to this object and all child objects, як показано на екрані 2. Якщо ви виконаєте цю операцію, настройки батьківської папки вже не будуть впливати на параметри безпеки поточного файлу або папки або будь-яких інших файлів або папок, розташованих нижче в ієрархічній структурі - майже у всіх випадках.

Два маловідомих виключення в цій системі захисту від успадкування дозволів можуть призвести до плутанини. Перше полягає в тому, що відмова в наданні доступу до файлу з правом читання (Read Attributes) недійсний, якщо батьківська папка дозволяє складати список каталогу. Якщо ви явно відмовляєте користувачам в доступі до файлу з правом читання, будь-який користувач, який має право складання списку вмісту каталогу, може також переглядати атрибути будь-якого файлу в даному каталозі. Очевидно, що це виняток порушує правила 2 і 3 - воно дозволяє записи «Дозволити» отримувати пріоритет над записом «Відмовити» і дає можливість дозволами батьківської папки отримувати пріоритет над обмеженнями, які накладені безпосередньо на об'єкт. Крім того, це виняток порушує правила 4 і 5, тому що, навіть якщо ви явно захистіть файл від успадкування дозволів, знявши прапорець Allow inheritable permissions from the parent to propagate to this object, батьківська папка буде як і раніше впливати на вирішення об'єкта.

Другий виняток полягає в тому, що відмова в дозволі на видалення (Delete Attributes) стосовно до файлу або папці не діє, якщо батьківська папка має дозвіл на видалення підпапок і файлів (Delete Subfolders and Files). Оскільки за замовчуванням майже всі папки мають дозвіл на видалення підпапок і файлів, відмова в дозволі на видалення файлу рідко матиме ефект. Цей виняток може призвести до плутанини, бо ви, наприклад, можете позбавити когось права на видалення того чи іншого файлу, а потім виявиться, що ця людина проте має право на його видалення. Це виключення з декількох правил спадкування, і знову-таки воно зберігає силу, навіть якщо ви явно захистіть файл від успадкування дозволів з боку його батьківської папки.

Але цим складності не вичерпуються. Можливо, ви подумали, що, якщо при наданні дозволу на видалення підпапок і файлів для деякої папки користувачі можуть видаляти підпапки та файли, з цього випливає, що при відмові в такому дозволі користувачі не зможуть видаляти підпапки та файли. Зовсім ні. Відмова в дозволі на видалення підпапок і файлів для тієї чи іншої папки, по суті, означає надання права застосовувати дозвіл на видалення до будь-яких дочірніх об'єктів. Для виключення можливості видалення файлів можна використовувати один з двох дозволів - дозвіл на видалення підпапок і файлів або дозвіл на видалення. Захист файлу від видалення - це процес, що складається з двох етапів. Спочатку потрібно відмовити в праві на видалення стосовно файлу, а потім - в праві видаляти підпапки та файли стосовно батьківської папки.

3. Дозвіл на виконання файлу може виявитися корисним

Вище я говорив про те, що адміністраторам не варто витрачати сили на встановлення дозволів з високим рівнем деталізації, але з цього правила, на мій погляд, є один виняток - це дозвіл на виконання файлу (Execute File). Одне зі стандартних дозволів формулюється як Read and Execute, але в дійсності для виконання файлу користувачеві не потрібен доступ з правом читання. У більшості випадків для виконання файлу користувачеві потрібен тільки доступ з правом Execute and Read Attributes. Більш того, зазвичай користувачеві не потрібно навіть надавати доступ з правом Read Attributes, тому що він автоматично отримає це право від батьківської папки, про що я вже згадував.

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

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

При наданні дозволу на виконання файлу деталізований контроль може бути корисним. Не будемо забувати, однак, що для виконання сценаріїв і командних файлів необхідно дотримання тих же умов, тільки, що називається, з точністю до навпаки: користувачеві повинно бути надано право на читання, а дозвіл на виконання файлу не потрібно. Цікаво відзначити, що в разі відмови в дозволі на виконання файлу стосовно компоненту ActiveX DLL або OLE Custom Control (OCX) користувачі позбавляються можливості звернення до файлу regsvr32.exe з метою реєстрації цього компонента.

4. Деякі дозволу не настільки корисні, як інші

Деякі дозволу на маніпуляції з файлами менш корисні, ніж інші, просто тому, що такі дозволи перевизначаються іншими прийнятими за замовчуванням системними привілеями. Неможливо, наприклад, відмовити у наданні дозволу приймати об'єкти у володіння (Take Ownership) тим користувачам, які мають системну привілей на відновлення файлів і каталогів (остання за замовчуванням надається адміністраторам і операторам резервного копіювання, оскільки ці користувачі мають системну привілей брати до володіння файли або інші об'єкти). Ви можете позбавити цієї системної привілеї адміністраторів, але, будучи адміністраторами, вони, в свою чергу, можуть відновити її.

По суті, дозвіл брати до володіння має мало сенсу. Справа в тому, що за замовчуванням брати до володіння файли можуть тільки члени групи адміністраторів або операторів резервного копіювання, і всякий користувач, що входить до складу однієї з цих груп, вже має системну привілей брати до володіння файли або інші об'єкти. Єдина ситуація, в якій слід було б застосовувати цей дозвіл, - це випадок, коли користувач або група не входить до складу групи адміністраторів, не має системної привілеї відновлювати файли і каталоги, але має право брати до володіння файли або інші об'єкти і ви хочете позбавити цього користувача або групу можливості прийняти у володіння конкретний набір файлів. Тільки в такому випадку дозвіл брати до володіння буде функціонувати, як очікується; в інших ситуаціях з ним просто не варто зв'язуватися.

Спеціальні дозволи на читання (Read Permissions) і на внесення змін (Change Permissions) незастосовні до власника файлу, навіть якщо адміністратор явно відмовить йому в цих дозволах. Отже, згадані дозволу незастосовні також до будь-якому користувачеві, що користується правом приймати у володіння файли або інші об'єкти. Якщо ви хочете відмовити комусь в дозволі на зчитування даних або на внесення змін, вам доведеться відмовити цьому користувачу в можливості приймати об'єкти у володіння.

Відзначимо, що хоча в дозволах на читання і в дозволах на внесення змін не міститься явно вираженого дозволу або обмеження на доступ до налаштувань аудиту (тобто до системних списками ACL-SACL), в більшості механізмів перегляду, таких як вкладка Security в діалоговому вікні програми Windows Explorer, не відображається список SACL, якщо ці дозволи (тобто дискреційні списки ACL-SACL) не надані.

Нарешті, вам, ймовірно, немає потреби встановлювати дозволу на переміщення по каталогам (Traverse Folder), оскільки за замовчуванням кожен користувач системи має привілей обходу перевірки переміщення (Bypass Traverse Checking), яка, по суті справи, зводить нанівець це дозвіл. Більш того, фахівці Microsoft давно вже рекомендують не здійснювати перевірок переміщення, бо відомо, що в результаті виникають проблеми з додатками, які не забезпечують коректної обробки помилок навігації по каталогам.

5. Дозволи на спільний доступ до ресурсів доповнюють, але не замінюють дозволів NTFS

Коли ви надаєте дозволу на спільне використання файлу, ці дозволи діють незалежно від дозволів NTFS на доступ до файлів і папок, але в поєднанні з даними дозволами. Система Windows розглядає обидва набору дозволів і використовує дозволу з тієї групи, де надається найменший обсяг прав.

Секрети системи NTFS

Управління доступом до файлів і папок в системі Windows - процес непростий; для забезпечення безпеки ресурсів необхідний ефективний механізм захисту. Саме такий механізм реалізований в моделі безпеки NTFS, яка дозволяє адміністратору жорстко контролювати дії користувачів, які здійснюють читання або запис в файлах системи і так чи інакше працюють з ними.

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

1. обмежується п'ятьма стандартними дозволами на звернення до файлів

Система NTFS дозволяє надавати 14 особливих дозволів, які точно визначають, яким чином користувач може звертатися до того чи іншого файлу. Ці дозволи досить деталізовані, тому, не вдаючись у подробиці, відзначимо, що в NTFS 14 дозволів зводяться до п'яти стандартним - або видовим - дозволами, як показано в таблиці. Наприклад, стандартні дозволи дають можливість надати користувачеві повний контроль (Full Control) над файлом, замість того щоб надавати йому окремо кожне з 14 особливих дозволів.

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

У вікні командного рядка добре видно, в чому полягає відмінність між записом в файл і приєднанням даних. Щоб записати дані в файл, потрібно ввести наступну команду:

C:> echo «new text»> test.txt

Якщо в програмі Notepad відкрити файл test.txt, ви побачите, що він містить один рядок - «new text».

Тепер спробуємо приєднати дані до файлу. Для цього можна використовувати наступну команду:

C:> echo «Line 2» >> test.txt

Тепер, якщо ви відкриєте файл test.txt в додатку Notepad, то побачите, що він містить два рядки:

«New text»

«Line 2»

На жаль, такі деталізовані дозволу часто неможливо використовувати. Зараз я поясню чому. Система NTFS «розуміє» різницю між записом і приєднанням даних, так що у вас може виникнути бажання встановити такий дозвіл, яке дозволяє приєднувати дані, але відмовляє в доступі з правом запису. Отже, встановимо дозвіл на доступ до файлу test.txt з наданням прав на виконання будь-яких операцій, крім запису даних (Write Data), як показано на екрані 1.

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

C:> echo «Line 3» >> test.txt

вам буде відмовлено в доступі. Більш того, тепер ви не зможете ні записувати дані в файл, ні приєднувати дані до файлу з командного рядка. Але і це ще не все. Якщо спробувати домогтися зворотного ефекту і дати дозвіл на запис даних (Write Data) з одночасною забороною на приєднання даних (Append Data), побачимо, що і ця комбінація не дає результату. Інакше кажучи, якщо ви блокуєте одну операцію, одночасно блокується і друга.

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

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

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

Отже, хоча система NTFS дозволяє надавати досить деталізовані дозволу, наша здатність реалізовувати ці дозволи обмежується тим, чи були враховані відповідні деталі розробниками програмного забезпечення. Ми можемо виявляти високу пильність і встановлювати досить деталізовані дозволу на доступ до файлів, але зазвичай наше прагнення враховувати більше обставин, ніж дозволяють п'ять стандартних дозволів, обертається марною тратою часу.

2. Пам'ятайте про двох винятки з порядку спадкування дозволів

Модель спадкування, яка використовується системою NTFS для управління доступом, грає важливу роль у визначенні того, хто має право доступу до того чи іншого файлу. Щоб визначитися з дозволами, Windows повинна звіритися зі списком управління доступом, що належать до даного файлу. Кожен файл і папка мають власний список управління доступом, де надається або блокується доступ для конкретних користувачів або груп. Але цей об'єкт може до того ж успадковувати дозволу від своєї батьківської папки або від будь-якої комбінації папок вищого рівня. Всі ці дозволи можуть конфліктувати один з одним - один список керування доступом може дозволяти користувачеві доступ до файлу, тоді як інший може явно відмовляти йому в доступі. Більш того, користувач може бути членом декількох груп, які мають різні дозволи.

Для вирішення проблеми конфліктуючих списків управління доступом в Windows використовується базовий набір правил:

• на будь-якому даному рівні дозволу від декількох груп об'єднуються;

• на будь-якому даному рівні негативні дозволу (заборони) мають пріоритет над позитивними;

• дозволу, надані об'єкту безпосередньо, мають пріоритет над успадкованими дозволами;

• дозволу, успадковані від «близьких родичів», мають пріоритет над дозволами, успадкованими від «далеких родичів».

Будь-який об'єкт може бути захищений від успадкування дозволів від батьківських папок.

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

Об'єкт можна захистити від процесу успадкування. Для цього в діалоговому вікні Advanced Security Settings потрібно перейти на вкладку Permissions і зняти прапорець Allow inheritable permissions from the parent to propagate to this object and all child objects, як показано на екрані 2. Якщо ви виконаєте цю операцію, настройки батьківської папки вже не будуть впливати на параметри безпеки поточного файлу або папки або будь-яких інших файлів або папок, розташованих нижче в ієрархічній структурі - майже у всіх випадках.

Два маловідомих виключення в цій системі захисту від успадкування дозволів можуть призвести до плутанини. Перше полягає в тому, що відмова в наданні доступу до файлу з правом читання (Read Attributes) недійсний, якщо батьківська папка дозволяє складати список каталогу. Якщо ви явно відмовляєте користувачам в доступі до файлу з правом читання, будь-який користувач, який має право складання списку вмісту каталогу, може також переглядати атрибути будь-якого файлу в даному каталозі. Очевидно, що це виняток порушує правила 2 і 3 - воно дозволяє записи «Дозволити» отримувати пріоритет над записом «Відмовити» і дає можливість дозволами батьківської папки отримувати пріоритет над обмеженнями, які накладені безпосередньо на об'єкт. Крім того, це виняток порушує правила 4 і 5, тому що, навіть якщо ви явно захистіть файл від успадкування дозволів, знявши прапорець Allow inheritable permissions from the parent to propagate to this object, батьківська папка буде як і раніше впливати на вирішення об'єкта.

Другий виняток полягає в тому, що відмова в дозволі на видалення (Delete Attributes) стосовно до файлу або папці не діє, якщо батьківська папка має дозвіл на видалення підпапок і файлів (Delete Subfolders and Files). Оскільки за замовчуванням майже всі папки мають дозвіл на видалення підпапок і файлів, відмова в дозволі на видалення файлу рідко матиме ефект. Цей виняток може призвести до плутанини, бо ви, наприклад, можете позбавити когось права на видалення того чи іншого файлу, а потім виявиться, що ця людина проте має право на його видалення. Це виключення з декількох правил спадкування, і знову-таки воно зберігає силу, навіть якщо ви явно захистіть файл від успадкування дозволів з боку його батьківської папки.

Але цим складності не вичерпуються. Можливо, ви подумали, що, якщо при наданні дозволу на видалення підпапок і файлів для деякої папки користувачі можуть видаляти підпапки та файли, з цього випливає, що при відмові в такому дозволі користувачі не зможуть видаляти підпапки та файли. Зовсім ні. Відмова в дозволі на видалення підпапок і файлів для тієї чи іншої папки, по суті, означає надання права застосовувати дозвіл на видалення до будь-яких дочірніх об'єктів. Для виключення можливості видалення файлів можна використовувати один з двох дозволів - дозвіл на видалення підпапок і файлів або дозвіл на видалення. Захист файлу від видалення - це процес, що складається з двох етапів. Спочатку потрібно відмовити в праві на видалення стосовно файлу, а потім - в праві видаляти підпапки та файли стосовно батьківської папки.

3. Дозвіл на виконання файлу може виявитися корисним

Вище я говорив про те, що адміністраторам не варто витрачати сили на встановлення дозволів з високим рівнем деталізації, але з цього правила, на мій погляд, є один виняток - це дозвіл на виконання файлу (Execute File). Одне зі стандартних дозволів формулюється як Read and Execute, але в дійсності для виконання файлу користувачеві не потрібен доступ з правом читання. У більшості випадків для виконання файлу користувачеві потрібен тільки доступ з правом Execute and Read Attributes. Більш того, зазвичай користувачеві не потрібно навіть надавати доступ з правом Read Attributes, тому що він автоматично отримає це право від батьківської папки, про що я вже згадував.

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

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

При наданні дозволу на виконання файлу деталізований контроль може бути корисним. Не будемо забувати, однак, що для виконання сценаріїв і командних файлів необхідно дотримання тих же умов, тільки, що називається, з точністю до навпаки: користувачеві повинно бути надано право на читання, а дозвіл на виконання файлу не потрібно. Цікаво відзначити, що в разі відмови в дозволі на виконання файлу стосовно компоненту ActiveX DLL або OLE Custom Control (OCX) користувачі позбавляються можливості звернення до файлу regsvr32.exe з метою реєстрації цього компонента.

4. Деякі дозволу не настільки корисні, як інші

Деякі дозволу на маніпуляції з файлами менш корисні, ніж інші, просто тому, що такі дозволи перевизначаються іншими прийнятими за замовчуванням системними привілеями. Неможливо, наприклад, відмовити у наданні дозволу приймати об'єкти у володіння (Take Ownership) тим користувачам, які мають системну привілей на відновлення файлів і каталогів (остання за замовчуванням надається адміністраторам і операторам резервного копіювання, оскільки ці користувачі мають системну привілей брати до володіння файли або інші об'єкти). Ви можете позбавити цієї системної привілеї адміністраторів, але, будучи адміністраторами, вони, в свою чергу, можуть відновити її.

По суті, дозвіл брати до володіння має мало сенсу. Справа в тому, що за замовчуванням брати до володіння файли можуть тільки члени групи адміністраторів або операторів резервного копіювання, і всякий користувач, що входить до складу однієї з цих груп, вже має системну привілей брати до володіння файли або інші об'єкти. Єдина ситуація, в якій слід було б застосовувати цей дозвіл, - це випадок, коли користувач або група не входить до складу групи адміністраторів, не має системної привілеї відновлювати файли і каталоги, але має право брати до володіння файли або інші об'єкти і ви хочете позбавити цього користувача або групу можливості прийняти у володіння конкретний набір файлів. Тільки в такому випадку дозвіл брати до володіння буде функціонувати, як очікується; в інших ситуаціях з ним просто не варто зв'язуватися.

Спеціальні дозволи на читання (Read Permissions) і на внесення змін (Change Permissions) незастосовні до власника файлу, навіть якщо адміністратор явно відмовить йому в цих дозволах. Отже, згадані дозволу незастосовні також до будь-якому користувачеві, що користується правом приймати у володіння файли або інші об'єкти. Якщо ви хочете відмовити комусь в дозволі на зчитування даних або на внесення змін, вам доведеться відмовити цьому користувачу в можливості приймати об'єкти у володіння.

Відзначимо, що хоча в дозволах на читання і в дозволах на внесення змін не міститься явно вираженого дозволу або обмеження на доступ до налаштувань аудиту (тобто до системних списками ACL-SACL), в більшості механізмів перегляду, таких як вкладка Security в діалоговому вікні програми Windows Explorer, не відображається список SACL, якщо ці дозволи (тобто дискреційні списки ACL-SACL) не надані.

Нарешті, вам, ймовірно, немає потреби встановлювати дозволу на переміщення по каталогам (Traverse Folder), оскільки за замовчуванням кожен користувач системи має привілей обходу перевірки переміщення (Bypass Traverse Checking), яка, по суті справи, зводить нанівець це дозвіл. Більш того, фахівці Microsoft давно вже рекомендують не здійснювати перевірок переміщення, бо відомо, що в результаті виникають проблеми з додатками, які не забезпечують коректної обробки помилок навігації по каталогам.

5. Дозволи на спільний доступ до ресурсів доповнюють, але не замінюють дозволів NTFS

Коли ви надаєте дозволу на спільне використання файлу, ці дозволи діють незалежно від дозволів NTFS на доступ до файлів і папок, але в поєднанні з даними дозволами. Система Windows розглядає обидва набору дозволів і використовує дозволу з тієї групи, де надається найменший обсяг прав.

Секрети системи NTFS

Управління доступом до файлів і папок в системі Windows - процес непростий; для забезпечення безпеки ресурсів необхідний ефективний механізм захисту. Саме такий механізм реалізований в моделі безпеки NTFS, яка дозволяє адміністратору жорстко контролювати дії користувачів, які здійснюють читання або запис в файлах системи і так чи інакше працюють з ними.

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

1. обмежується п'ятьма стандартними дозволами на звернення до файлів

Система NTFS дозволяє надавати 14 особливих дозволів, які точно визначають, яким чином користувач може звертатися до того чи іншого файлу. Ці дозволи досить деталізовані, тому, не вдаючись у подробиці, відзначимо, що в NTFS 14 дозволів зводяться до п'яти стандартним - або видовим - дозволами, як показано в таблиці. Наприклад, стандартні дозволи дають можливість надати користувачеві повний контроль (Full Control) над файлом, замість того щоб надавати йому окремо кожне з 14 особливих дозволів.

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

У вікні командного рядка добре видно, в чому полягає відмінність між записом в файл і приєднанням даних. Щоб записати дані в файл, потрібно ввести наступну команду:

C:> echo «new text»> test.txt

Якщо в програмі Notepad відкрити файл test.txt, ви побачите, що він містить один рядок - «new text».

Тепер спробуємо приєднати дані до файлу. Для цього можна використовувати наступну команду:

C:> echo «Line 2» >> test.txt

Тепер, якщо ви відкриєте файл test.txt в додатку Notepad, то побачите, що він містить два рядки:

«New text»

«Line 2»

На жаль, такі деталізовані дозволу часто неможливо використовувати. Зараз я поясню чому. Система NTFS «розуміє» різницю між записом і приєднанням даних, так що у вас може виникнути бажання встановити такий дозвіл, яке дозволяє приєднувати дані, але відмовляє в доступі з правом запису. Отже, встановимо дозвіл на доступ до файлу test.txt з наданням прав на виконання будь-яких операцій, крім запису даних (Write Data), як показано на екрані 1.

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

C:> echo «Line 3» >> test.txt

вам буде відмовлено в доступі. Більш того, тепер ви не зможете ні записувати дані в файл, ні приєднувати дані до файлу з командного рядка. Але і це ще не все. Якщо спробувати домогтися зворотного ефекту і дати дозвіл на запис даних (Write Data) з одночасною забороною на приєднання даних (Append Data), побачимо, що і ця комбінація не дає результату. Інакше кажучи, якщо ви блокуєте одну операцію, одночасно блокується і друга.

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

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

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

Отже, хоча система NTFS дозволяє надавати досить деталізовані дозволу, наша здатність реалізовувати ці дозволи обмежується тим, чи були враховані відповідні деталі розробниками програмного забезпечення. Ми можемо виявляти високу пильність і встановлювати досить деталізовані дозволу на доступ до файлів, але зазвичай наше прагнення враховувати більше обставин, ніж дозволяють п'ять стандартних дозволів, обертається марною тратою часу.

2. Пам'ятайте про двох винятки з порядку спадкування дозволів

Модель спадкування, яка використовується системою NTFS для управління доступом, грає важливу роль у визначенні того, хто має право доступу до того чи іншого файлу. Щоб визначитися з дозволами, Windows повинна звіритися зі списком управління доступом, що належать до даного файлу. Кожен файл і папка мають власний список управління доступом, де надається або блокується доступ для конкретних користувачів або груп. Але цей об'єкт може до того ж успадковувати дозволу від своєї батьківської папки або від будь-якої комбінації папок вищого рівня. Всі ці дозволи можуть конфліктувати один з одним - один список керування доступом може дозволяти користувачеві доступ до файлу, тоді як інший може явно відмовляти йому в доступі. Більш того, користувач може бути членом декількох груп, які мають різні дозволи.

Для вирішення проблеми конфліктуючих списків управління доступом в Windows використовується базовий набір правил:

• на будь-якому даному рівні дозволу від декількох груп об'єднуються;

• на будь-якому даному рівні негативні дозволу (заборони) мають пріоритет над позитивними;

• дозволу, надані об'єкту безпосередньо, мають пріоритет над успадкованими дозволами;

• дозволу, успадковані від «близьких родичів», мають пріоритет над дозволами, успадкованими від «далеких родичів».

Будь-який об'єкт може бути захищений від успадкування дозволів від батьківських папок.

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

Об'єкт можна захистити від процесу успадкування. Для цього в діалоговому вікні Advanced Security Settings потрібно перейти на вкладку Permissions і зняти прапорець Allow inheritable permissions from the parent to propagate to this object and all child objects, як показано на екрані 2. Якщо ви виконаєте цю операцію, настройки батьківської папки вже не будуть впливати на параметри безпеки поточного файлу або папки або будь-яких інших файлів або папок, розташованих нижче в ієрархічній структурі - майже у всіх випадках.

Два маловідомих виключення в цій системі захисту від успадкування дозволів можуть призвести до плутанини. Перше полягає в тому, що відмова в наданні доступу до файлу з правом читання (Read Attributes) недійсний, якщо батьківська папка дозволяє складати список каталогу. Якщо ви явно відмовляєте користувачам в доступі до файлу з правом читання, будь-який користувач, який має право складання списку вмісту каталогу, може також переглядати атрибути будь-якого файлу в даному каталозі. Очевидно, що це виняток порушує правила 2 і 3 - воно дозволяє записи «Дозволити» отримувати пріоритет над записом «Відмовити» і дає можливість дозволами батьківської папки отримувати пріоритет над обмеженнями, які накладені безпосередньо на об'єкт. Крім того, це виняток порушує правила 4 і 5, тому що, навіть якщо ви явно захистіть файл від успадкування дозволів, знявши прапорець Allow inheritable permissions from the parent to propagate to this object, батьківська папка буде як і раніше впливати на вирішення об'єкта.

Другий виняток полягає в тому, що відмова в дозволі на видалення (Delete Attributes) стосовно до файлу або папці не діє, якщо батьківська папка має дозвіл на видалення підпапок і файлів (Delete Subfolders and Files). Оскільки за замовчуванням майже всі папки мають дозвіл на видалення підпапок і файлів, відмова в дозволі на видалення файлу рідко матиме ефект. Цей виняток може призвести до плутанини, бо ви, наприклад, можете позбавити когось права на видалення того чи іншого файлу, а потім виявиться, що ця людина проте має право на його видалення. Це виключення з декількох правил спадкування, і знову-таки воно зберігає силу, навіть якщо ви явно захистіть файл від успадкування дозволів з боку його батьківської папки.

Але цим складності не вичерпуються. Можливо, ви подумали, що, якщо при наданні дозволу на видалення підпапок і файлів для деякої папки користувачі можуть видаляти підпапки та файли, з цього випливає, що при відмові в такому дозволі користувачі не зможуть видаляти підпапки та файли. Зовсім ні. Відмова в дозволі на видалення підпапок і файлів для тієї чи іншої папки, по суті, означає надання права застосовувати дозвіл на видалення до будь-яких дочірніх об'єктів. Для виключення можливості видалення файлів можна використовувати один з двох дозволів - дозвіл на видалення підпапок і файлів або дозвіл на видалення. Захист файлу від видалення - це процес, що складається з двох етапів. Спочатку потрібно відмовити в праві на видалення стосовно файлу, а потім - в праві видаляти підпапки та файли стосовно батьківської папки.

3. Дозвіл на виконання файлу може виявитися корисним

Вище я говорив про те, що адміністраторам не варто витрачати сили на встановлення дозволів з високим рівнем деталізації, але з цього правила, на мій погляд, є один виняток - це дозвіл на виконання файлу (Execute File). Одне зі стандартних дозволів формулюється як Read and Execute, але в дійсності для виконання файлу користувачеві не потрібен доступ з правом читання. У більшості випадків для виконання файлу користувачеві потрібен тільки доступ з правом Execute and Read Attributes. Більш того, зазвичай користувачеві не потрібно навіть надавати доступ з правом Read Attributes, тому що він автоматично отримає це право від батьківської папки, про що я вже згадував.

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

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

При наданні дозволу на виконання файлу деталізований контроль може бути корисним. Не будемо забувати, однак, що для виконання сценаріїв і командних файлів необхідно дотримання тих же умов, тільки, що називається, з точністю до навпаки: користувачеві повинно бути надано право на читання, а дозвіл на виконання файлу не потрібно. Цікаво відзначити, що в разі відмови в дозволі на виконання файлу стосовно компоненту ActiveX DLL або OLE Custom Control (OCX) користувачі позбавляються можливості звернення до файлу regsvr32.exe з метою реєстрації цього компонента.

4. Деякі дозволу не настільки корисні, як інші

Деякі дозволу на маніпуляції з файлами менш корисні, ніж інші, просто тому, що такі дозволи перевизначаються іншими прийнятими за замовчуванням системними привілеями. Неможливо, наприклад, відмовити у наданні дозволу приймати об'єкти у володіння (Take Ownership) тим користувачам, які мають системну привілей на відновлення файлів і каталогів (остання за замовчуванням надається адміністраторам і операторам резервного копіювання, оскільки ці користувачі мають системну привілей брати до володіння файли або інші об'єкти). Ви можете позбавити цієї системної привілеї адміністраторів, але, будучи адміністраторами, вони, в свою чергу, можуть відновити її.

По суті, дозвіл брати до володіння має мало сенсу. Справа в тому, що за замовчуванням брати до володіння файли можуть тільки члени групи адміністраторів або операторів резервного копіювання, і всякий користувач, що входить до складу однієї з цих груп, вже має системну привілей брати до володіння файли або інші об'єкти. Єдина ситуація, в якій слід було б застосовувати цей дозвіл, - це випадок, коли користувач або група не входить до складу групи адміністраторів, не має системної привілеї відновлювати файли і каталоги, але має право брати до володіння файли або інші об'єкти і ви хочете позбавити цього користувача або групу можливості прийняти у володіння конкретний набір файлів. Тільки в такому випадку дозвіл брати до володіння буде функціонувати, як очікується; в інших ситуаціях з ним просто не варто зв'язуватися.

Спеціальні дозволи на читання (Read Permissions) і на внесення змін (Change Permissions) незастосовні до власника файлу, навіть якщо адміністратор явно відмовить йому в цих дозволах. Отже, згадані дозволу незастосовні також до будь-якому користувачеві, що користується правом приймати у володіння файли або інші об'єкти. Якщо ви хочете відмовити комусь в дозволі на зчитування даних або на внесення змін, вам доведеться відмовити цьому користувачу в можливості приймати об'єкти у володіння.

Відзначимо, що хоча в дозволах на читання і в дозволах на внесення змін не міститься явно вираженого дозволу або обмеження на доступ до налаштувань аудиту (тобто до системних списками ACL-SACL), в більшості механізмів перегляду, таких як вкладка Security в діалоговому вікні програми Windows Explorer, не відображається список SACL, якщо ці дозволи (тобто дискреційні списки ACL-SACL) не надані.

Нарешті, вам, ймовірно, немає потреби встановлювати дозволу на переміщення по каталогам (Traverse Folder), оскільки за замовчуванням кожен користувач системи має привілей обходу перевірки переміщення (Bypass Traverse Checking), яка, по суті справи, зводить нанівець це дозвіл. Більш того, фахівці Microsoft давно вже рекомендують не здійснювати перевірок переміщення, бо відомо, що в результаті виникають проблеми з додатками, які не забезпечують коректної обробки помилок навігації по каталогам.

5. Дозволи на спільний доступ до ресурсів доповнюють, але не замінюють дозволів NTFS

Коли ви надаєте дозволу на спільне використання файлу, ці дозволи діють незалежно від дозволів NTFS на доступ до файлів і папок, але в поєднанні з даними дозволами. Система Windows розглядає обидва набору дозволів і використовує дозволу з тієї групи, де надається найменший обсяг прав.

Дозволи NTFS мають більший пріоритет, ніж дозволу на спільний доступ до ресурсів. Якщо останні й управляють доступом до файлів, розміщених на мережевих ресурсах, то вони не можуть перешкодити користувачам звернутися до цих файлів безпосередньо в системі або через службу терміналів. Тому я рекомендую читачам при регулюванні доступу завжди покладатися на вирішення NTFS і використовувати дозволу на спільний доступ до файлів тільки для того, щоб накласти додаткові обмеження на права користувачів мережі.

Крім того, важливо відзначити, що дозволу на доступ до кожного спільно використовуваному ресурсу стосуються лише даного ресурсу - вони не успадковуються і не поширюються на окремо збережені спільно використовувані ресурси, навіть якщо останні розташовуються на більш низьких поверхах тієї ж структури фізичного каталогу. Нехай, наприклад, у вас є призначений для всіх користувачів розділяється ресурс, розташований в каталозі D: users. Всі користувачі можуть звертатися до цього ресурсу і до всіх об'єктів, розташованим на більш низьких рівнях структури. Тепер уявіть собі, що ви створюєте призначений тільки для адміністраторів ресурс за адресою D: usersadmin. Другий ресурс, хоча він і є вкладеним в перший, не має з ним ніякого зв'язку. Навіть якщо ви відмовите звичайним користувачам в доступі до ресурсу D: usersadmin, вони зможуть звернутися до цієї папки, відкривши каталог D: users і перейшовши в папку admin. Для блокування доступу користувачів до каталогу admin доведеться призначити відповідні дозволи NTFS. Щоб такі ситуації не виникали, в більшості випадків краще уникати вкладених структур спільно використовуваних ресурсів.

6. Прив'язуйте дозволу до вбудованим групам

При призначенні дозволів на звернення до файлів і папок слід використовувати великий набір вбудованих груп, до яких Windows автоматично зараховує користувачів в залежності від того, як вони реєструються в системі. Існує, наприклад, група віддалених користувачів настільних систем (Remote Desktop Users). Можна встановлювати досить деталізовані дозволу NTFS в залежності від типу реєстрації. Так, у вас може виникнути необхідність надати доступ до певних конфіденційних файлів тільки адміністратору або користувачу, який входить в систему з локальної консолі. Це можна зробити, надавши доступ тільки групам Administrators і Interactive Logon Users. Можна також обмежити доступ до певних файлів, так щоб вони були доступні лише для облікових записів, зареєстрованих як служби. Повний список вбудованих учасників безпеки наведено в статті «Well-known security identifiers in Windows operating systems», опублікованої за адресою http://support.microsoft.com/kb/243330 .

(Додаткові відомості про вбудованих учасників безпеки містяться також в статті «Вбудовані учасники системи безпеки» , Опублікованій в Windows ITPro / RE № 1 за 2006 р - Прим. ред.).

7. Проявляйте обережність при використанні групи Everyone

Прийшов час дати остання порада: проявляйте обережність при роботі з групою Everyone. У версіях Windows, випущених до виходу в світ Windows XP, в групу Everyone за замовчуванням включалися анонімні користувачі, тому адміністраторам завжди радили не надавати права доступу членам цієї групи. Але в версіях Windows XP, Windows Server 2003 і Windows Vista анонімні користувачі за замовчуванням не входять в групу Everyone, так що в залежності від конкретних дозволів відмову в доступі членам групи Everyone не означає відмови анонімним користувачам. Найбезпечніший спосіб заблокувати доступ до ресурсів з боку анонімних і інших небажаних користувачів полягає не в тому, щоб відмовляти їм у праві доступу, а в тому, щоб надавати це право тільки конкретним користувачам і групам.

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

(Додаткову інформацію про дозволи NTFS і дозволи на звернення до ресурсів можна знайти в статті «Путівник по дозволам файлової системи» за адресою http://www.osp.ru/win2000/2007/06/4367585/ - Прим. ред.).

Марк Барнетт ( [email protected] ) - незалежний консультант з безпеки і автор, який спеціалізується на проблемах безпеки Windows. Володар сертифікату IIS MVP