Вбудовані учасники системи безпеки, windows it pro

ІТ-інфраструктура для вашого підприємства

Ефективне використання потужних ідентифікаторів

На відміну від типових учасників безпеки, цих учасників не можна перейменувати або видалити. Неможливо також створити власних вбудованих учасників безпеки; вони однакові у всіх системах Windows, хоча список вбудованих учасників безпеки в різних версіях злегка розрізняється. Крім того, вбудований учасник безпеки має один і той же SID в будь-якій системі Windows. Наприклад, SID S-1-5-10 завжди надається учаснику Self, а SID S-1-3-0 завжди представляє учасника Creator Owner.

Огляд вбудованих учасників безпеки

Адміністрування вбудованих учасників безпеки

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

Вбудованих учасників безпеки можна додати до інших груп і списками управління доступом (ACL) об'єктів Windows. В AD можна навіть делегувати дозволу вбудованим учасникам безпеки. Як не дивно, при першій спробі додати вбудованого учасника безпеки в іншу групу його не вдається знайти в оснащенні Active Directory Users and Computers консолі MMC. Необхідно знати правильне ім'я вбудованого учасника безпеки; для пошуку об'єкта можна задіяти інструментарій вибору об'єктів оснастки Active Directory Users and Computers. Справа в тому, що в оснащенні Active Directory Users and Computers зроблений акцент на управління даними в контексті іменування домену AD, а вбудовані учасники безпеки зберігаються в контексті іменування конфігурації AD. Та ж проблема виникає при використанні оснащення MMC Local Users and Groups. В цьому випадку вбудовані учасники безпеки приховані від користувача.

В оснащенні Active Directory Users and Computers вбудований учасник безпеки відображається в контейнері ForeignSecurityPrincipals. Наприклад, якщо ввести вбудованого учасника безпеки Authenticated Users в групу Print Operators, то елемент Authenticated Users буде додано до контейнер ForeignSecurityPrincipals (екран 3). Слід зазначити, що в легкочитаємий іменах більшості вбудованих учасників безпеки присутній рядок NT AUTHORITY. NT AUTHORITY - диспетчер безпеки у вбудованому домені безпеки Windows, який існує в кожній системі Windows.

Вбудованих учасників безпеки можна додавати в інші групи або в списки управління доступом (ACL) до ресурсів з командного рядка. Це можна зробити за допомогою команд Net Group і Net Localgroup. Наприклад, щоб додати групу Interactive в локальну групу Backup Operators, слід ввести команду

Наприклад, щоб надати групі Local Service право читання в розділі реєстру MyApplication, слід ввести команду

Authenticated Users і Everyone

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

System, Local Service і Network Service

Дозволи System можна порівняти з обліковим записом root в UNIX. При запуску служби або програми в контексті безпеки System дана служба або додаток має майже необмеженими дозволами в системі Windows. Наприклад, якщо служба реєструється на контролері домену (DC) з використанням вбудованого учасника безпеки System, то вона отримує права локальної системи на DC. Отримавши контроль над службою, зловмисник може внести зміни в AD. Слід бути обережним - діючи відповідно до принципу мінімальності достатніх дозволів, краще уникати використання System.

Network Service забезпечує мінімальний рівень дозволів для служб, яким необхідний доступ до інших комп'ютерів в мережі. Як і служба з дозволами System, служба Network Service звертається до мережевих ресурсів з даними облікового запису комп'ютера. Службам Domain Name System (DNS) і Remote Procedure Call (RPC) за замовчуванням присвоюються дозволу Network Service. Щоб налаштувати службу на використання Network Service, слід ввести NT AUTHORITYNetworkService на вкладці Log On діалогового вікна Alerter Properties. Пароль не потрібен.

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

За допомогою майстра Trust Wizard або властивостей довірливого ставлення можна налаштувати довірчі відносини в лісі або зовнішні по відношенню до лісу для селективної аутентифікації. Для настройки селективної аутентифікації з діалогового вікна Properties довірчих відносин слід перейти на вкладку Authentication і активізувати Selective Authentication.

Якщо ліс або зовнішнє довірливе ставлення використовують селективну аутентифікацію, а користувач намагається звернутися до ресурсу в іншому лісі (задіюючи довірчі відносини між лісами), то Windows додає до маркера доступу користувача вбудованого учасника безпеки Other Organization. Користувачі, які звертаються до ресурсів, застосовуючи довірче відношення між лісами, за замовчуванням мають в своєму маркері доступу вбудованого учасника безпеки This Organization. Коли користувач задіє довірчі відносини в лісі або зовнішнє відношення між лісами без селективної аутентифікації, Windows додає This Organization до маркера доступу даного користувача. В цьому випадку членство в групі This Organization таке ж, як в групі Authenticated Users.

Restricted Code

Якщо маркер доступу користувача в своєму розпорядженні вбудованим учасником безпеки Restricted Code, то Windows скасовує всі дозволи для користувача, крім Bypass Traverse Checking. В результаті програма не може отримати доступ до профілю користувача, і дозволяється тільки доступ по Read до баз даних налаштувань в реєстрі HKEY_LOCAL_MACHINE і HKEY_CURRENT_USER.

Типи Logon і Authentication

Self, Creator Owner і Creator Group

Кілька ієрархічних структур об'єктів Windows (в тому числі AD, реєстр і файлову систему) забезпечують успадкування дозволів. Дозволи визначаються в батьківському об'єкті, а потім автоматично передаються дочірніх об'єктів. Windows має вбудованими учасниками безпеки Self, Creator Owner і Creator Group для адміністрування дозволів в цих ієрархічних структурах.

Як правило, всі три учасники вводяться в список управління доступом (ACL) батьківського об'єкта, а потім дочірні об'єкти успадковують цих учасників наступним чином.

За замовчуванням Windows надає дозвіл на читання для Self на атрибут членства в групі. Тому всі члени групи можуть бачити інших користувачів, що належать до цієї групи. AD також надає групі Authenticated Users доступ на читання до списку членів групи, і користувачі з Authenticated Users теж бачать цю інформацію.

Потужний, але складний інструмент

Поділіться матеріалом з колегами і друзями