Права у Windows NTFS
У цій статті я розповім про методи NTFS та нові можливості, які з'явилися у Windows 2000, Windows XP та Windows 2003 Server.
Права Windows NTFS
Хоча розмежування прав у Windows з'явилося вже давно, я все ще стикаюся з адміністраторами, які не знають про нові зміни, які вже давно з'явилися разом з Windows 2000. Коли Microsoft випустила Windows 2000, вони випустили нову версію NTFS, під номером 5. Нові права NTFS виконували в основному такий же логічний контроль, що й у попередній версії, яка була у Windows NT, однак, з'явилися деякі нові та радикальні зміни, що дозволяють успадковувати права, а також налаштовувати їх окремо для кожного файлу та папки. Т.к. права NTFS тепер стали застосовні для кожного файлу, папки, ключа в реєстрі (Registry key), принтера, та об'єкта Active Directory, то важливо зрозуміти нові методи та можливості, які стали доступні з Windows 2000, Windows XP, або Windows 2003 Server, встановлені контролю ресурсів.
Стандартні права
Стандартні права – це права, які дозволяють контролювати широкий спектр окремих прав. Найпопулярніше і має сумну популярність право - Full Control (Повний доступ). Це те, що кожен хоче, але насправді лише деякі повинні мати. Повний доступ дозволяє користувачеві, для якого воно призначене, робити все, що завгодно з об'єктом. Інші стандартні права включають такі:
Modify (на зміну) Read & Execute (на читання та виконання) Read (на читання) Write (на запис)
Папки мають такі самі стандартні права, як і файли, за винятком одного додаткового стандартного права під назвою “List Folder Contents” (список вмісту папок).
Якщо ви дивитесяна ключі реєстру (Registry keys), принтери та об'єкти Active Directory, існує абсолютно різний набір стандартних прав для цих об'єктів. Закладка security для кожного та перелічених вище об'єктів, відображає список стандартних прав, що можна побачити на малюнку 1 для типової організаційної одиниці (organizational unit - OU) в Active Directory.
Малюнок 1 : Стандартні права для OU в Active Directory
Розширені права
Розширені права – це спеціальні права, згруповані разом для створення стандартних прав. Т.к. розширені права використовуються у поєднаннях для створення стандартних прав, загалом їх набагато більше. Для файлу список розширених прав буде виглядати так:
Full Control Файл файлів/Execute File List Folder/Read Data Read Attributes Read Extended Attributes Create Files/Write Data Create Folders/Append Data Write Attributes Write Extended Attributes Delete Read Permissions Change Permissions Take Ownership
Наприклад, набір розширених прав, які використовуються для створення стандартного права Read (право на читання), включають:
List Folder/Read Data Read Attributes Read Extended Attributes Read Permissions
Коли ви встановлюєте розширені права для папки, вони ідентичні правам для файлу. Однак, коли ви досліджуєте розширені права для принтера або ключа реєстру (Registry key), вони повністю різняться. Якщо ви хочете побачити потужність, яку має NTFS 5.0 в області контролю доступу, то найкраще це зробити з OU в Active Directory. На перший погляд, я нарахував понад 10,000 різних розширених прав, які ви можете встановити для OU, частину цього списку ви можете побачити нижчемалюнку 2.
Малюнок 2 : Розширені права для OU в Active Directory
Inherited (успадковані) та Explicit (прямі) права
Існують два типи прав, які можна побачити для будь-якого елемента (користувача, комп'ютера або групи) зі списку access control list (ACL). Якщо ми подивимося на кореневу директорію, C:, ви можете додати або змінити права на будь-який елемент з ACL. Якщо ви створюєте нову папку в C:, припустимо, нову папку під назвою Data (C:\Data), то ви не зможете змінити права, для будь-якого існуючого елемента. Це тому, що права папки C: автоматично успадковуються для всіх дочірніх папок. Якщо ви не хочете, щоб права папки C: успадковувалися для папки C:\Data, але хочете, щоб вони, як і раніше, успадковувалися для інших дочірніх папок для папки C:, то ви повинні налаштувати папку C:\Data, скасувавши успадкування просто прибравши галочку з поля “Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here”, що показано малюнку 3.
Малюнок 3 : Ви не можете змінювати спадкові права для будь-якої папки або файлу
На будь-якому рівні в структурі ресурсів ви завжди можете додавати нові елементи в ACL. Ці елементи, особливо цільового ресурсу, називаються прямими правами (explicit permissions), т.к. вони налаштовуються безпосередньо ресурсу. Якщо увімкнено спадкування за умовчанням для всіх дочірніх файлів і папок, ці прямі права будуть успадковані для всіх дочірніх ресурсів, так само як і від C:\ для C:\Data. Легко побачити різницю між наследуемыми правами і прямими правами, з допомогою галочки на елементі. Якщо вона не сірого кольору, значить права прямі.
Дозволяючі та забороняючі права
При встановленніВи повинні вказати, що необхідно зробити для певного елемента – дозволити доступ (Allow) або заборонити (Deny). Local Security Authority (LSASS) коли здійснює контроль доступу до ресурсу, ґрунтується на security ID (SID), який міститься в ACL, а потім порівнюється з SID, який надається користувачеві при вході в систему. Якщо SID присвоєний користувачеві перебуває у ACL, то LSASS повинен визначити, який тип доступу встановлений об'єкта — Allow чи Deny. Права Allow та Deny успадковуються також для всієї структури, як і для описаних вище прав.
Малюнок 4 : Елементи Deny в ACL призводять до появи попередження
Це не найпопулярніший спосіб налаштування ресурсів використовувати права Deny. Набагато частіше використовується виняток користувача або групи зі списку ACL замість того, щоб застосовувати для них прямі права Deny. Той факт, що SID користувача або групи не знаходиться в ACL, призводить до того ж результату – немає доступу до ресурсу (“No Access”), не потребуючи спеціальних налаштувань ACL. Тільки дуже рідко потрібно використовувати прямі права Deny. Відмова у доступі до ресурсу помилково з ACL легше налагоджувати, керувати та налаштовувати.
Пріоритет прав
Я постійно чую від своїх студентів та інших мережевих адміністраторів (навіть у діалоговому вікні на малюнку 4), що права Deny мають пріоритет над правами Allow. На жаль це не завжди так. Щоб довести мою думку, давай подивимося на сценарій, який ви також можете відтворити. Він доведе, що забороняючі права (Deny permissions) не завжди мають пріоритет над дозвільними правами (Allow permissions).
У сценарії ми розглянемо папку C:\Data\HR, у якій містяться як спільні, і приватні файли. Ми дозволимо папці C:\Data\HRуспадковувати права від папки C:\Data, яка успадковує у свою чергу лише базові права від кореневої папки. Ми також включили групу HR до ACL, надавши цій групі права Allow-Read & Execute. І нарешті включимо запис в ACL для не HR групи, для якої встановлено права Deny-Full Control.
У папці HR знаходяться два файли: Public.doc та Private.doc. Для папки Public дозволені лише нормальні спадкові права, тому жодних спеціальних прав до ACL не додається. Однак, файл private має деякі прямі права, додані до ACL. Т.к. групі Executive необхідно прочитати вміст папки private, ця група додається безпосередньо з правами Allow-Read & Execute. В результаті цієї конфігурації, показаної на малюнку 5, чітко видно, що дозвільні права (Allow permission) для групи Executive мають більш високий пріоритет, ніж забороняючі права (Deny permission) для групи не HR. Т.к. кожен право executive включено в обидві групи, то ви можете бачити, що в цьому випадку дозвільні права (Allow permissions) мають пріоритет над забороняючими правами (Deny permissions).
Малюнок 5 : Дозволяючі права мають перевагу над забороняючими правами (Deny permissions)
Цей сценарій доводить, що є ієрархія прав для ресурсів у NTFS 5.0. Ієрархія пріоритетів для прав можна підсумувати за допомогою наступного списку, в якому права з найвищим пріоритетом знаходяться на чолі списку:
Explicit Deny Explicit Allow Inherited Deny Inherited Allow
Резюме
Права майже аналогічні в Windows NT NTFS 4.0 і Windows 2000/XP/2003 NTFS 5.0. Одне з основних відмінностей – це спосіб, з якого відбувається успадкування цих прав всередині структури. Раніше було так, що якщо мали рацію Deny вACL, то вони завжди бралися до уваги першими, а лише за ними слідували права Allow. Тепер права ієрархічно перевіряються не лише за критерієм Deny-Allow, але й за тим критерієм, чи успадковане це право або було встановлено для ресурсу безпосередньо.