Вивчаємо безпеку Windows 2003 h2>
В
січні 2002 року Microsoft виступила з ініціативою "Trustworthy
Computing ", спрямованої на забезпечення безпеки платформи Windows.
Ця подія безпосередньо вплинуло на відстрочення дати випуску наступної хвилі
продуктів Microsoft (зібраних під "парасолькою". NET), але
додаткові місяці зусиль розробників призвели до того, що нові продукти
стали набагато безпечніше і стабільніше, ніж будь-які з їхніх попередників. p>
Марсін Поліч (Marcin Policht) p>
В
січні 2002 року Microsoft виступила з ініціативою "Trustworthy
Computing ", спрямованої на забезпечення безпеки платформи Windows.
Ця подія безпосередньо вплинуло на відстрочення дати випуску наступної хвилі
продуктів Microsoft (зібраних під "парасолькою". NET), але
додаткові місяці зусиль розробників призвели до того, що нові продукти
стали набагато безпечніше і стабільніше, ніж будь-які з їхніх попередників. p>
Ця
стаття є першою в серії, яка охоплює покращення в області
безпеки, введені в ОС Windows 2003 Server. p>
Нові
функції розроблені з тим, щоб запропонувати зростання рівня безпеки,
практично, в кожній сфері функціональних можливостей нової операційної
системи. Ми почнемо з того з них, що впливає на величезне число
користувачів та адміністраторів Windows. p>
Дозволи NTFS і загальні дозволи, що визначаються за
замовчуванням p>
В
попередніх версіях Windows дозволу за замовчуванням наділяли правом Full Control
(Повний доступ) групу Everyone (Все) (для обох систем дозволів), що робило
файлову систему повністю незахищеною (у разі локального доступу до
системі). Починаючи з Windows XP Professional, цей підхід зазнав змін. P>
Дозволи
NTFS на кореневому диску, що надаються групі Everyone обмежені правом Read
(Читання) і Execute (Виконання) і надаються тільки на кореневому каталозі.
Це означає, що група Everyont не може успадковувати ці дозволи на будь-якому
з підкаталогів, створеному в кореневому каталозі. Група Everyone також виключена
зі списку управління доступом (Access Control List) для забезпечення більшої
безпеки таких областей файлової системи, як Program Files або каталоги
Windows. Користувачі, що на додаток до прав Read і Execute, можуть створювати
підкаталоги (здатні наслідувати права) і файли в підкаталогах. (Зверніть
увагу, що це не поширюється на кореневій диск). Рівень дозволів,
що надаються обліковий запис System і членам локальної адміністративної
групи, не змінюється - вони, як і раніше, зберігають права Full Control по
відношенню до кореневого каталогу і всіх його підкаталогів і файлів. Група Creator
Owner наділена правом Full Control до підкаталогу і файлів у них, що дозволяє
користувачам повною мірою керувати створюваними ними підкаталогами. p>
Загальні
дозволу для новостворюваних загальних ресурсів для групи Everyone тепер
обмежені правом Read. p>
Крім
того, група Everyone більше не включає до свого складу анонімний ідентифікатор
безпеки (anonymous SID), що дає можливість несанкціонованого доступу до
файлової системи. Ви також можете швидко перевірити, наскільки добре працює
ваша система безпеки на рівні NTFS, за допомогою вкладки Effective
Permissions вікна Advanced Security Settings для вибраного файлу або папки. Це
дозволяє усунути необхідність приблизної оцінки і складного аналізу
успадкування і прямого призначення прав NTFS. Проте, ця функція не приймає в
розрахунок загальні дозволу на користування ресурсом. p>
Володіння файлами та папками p>
Тепер
ви можете не тільки заволодіти обраним об'єктом файлової системи (файлом або
папкою), але також передати його будь-якому користувачеві, використовуючи вкладку Owner
діалогового вікна Advanced Security Setting цього файлу або папки. Ця функція
спрощує роботу з дисковими квотами Windows, заснованими на властивостях володіння.
Наприклад, адміністратор створює новий файл від імені користувача (наприклад,
через копіювання файлу або встановлення нової програми), що призводить до того,
що адміністратор стає власником цього файлу. Отже, розмір нового
файлу не буде зараховуватися в ліміт квоти цього користувача. У минулому, це
рішення вимагало громіздкого обхідного шляху або використання інструментів
сторонніх виробників. Тепер, за допомогою функціональної можливості
призначення власника, доступного через інтерфейс користувача, ця проблема
може бути вирішена дуже просто (для будь-якого типу операційної системи,
використовує NTFS - включаючи Windows NT 4.0, 2000 і XP Professional - якщо це
зміна здійснюється на Windows 2003 Server). p>
Зверніть
увагу на те, що подібні функціональні можливості (ефективні дозволу
і призначення власника) також доступні для об'єктів Active Directory,
керованих з серверів Windows 2003 (через вкладки Effective Permissions і
Owner в діалоговому вікні Advanced Security оснащення Active Directory Users and
Computers). P>
Налаштування служб Windows p>
Зміни
в настройках служб Windows можуть бути згруповані у дві основні категорії: p>
Служби, що запускаються при включенні:
Деякі, найбільш вразливі служби, такі як Clipbook, Network DDE (і Network
DDE DSDM), Telnet і WebClient, є відключеними за замовчуванням. Інші
активуються тільки в міру необхідності (наприклад, Intersite Messaging в ході
підвищення статусу контролера домену, або Routing and Remote Access Service
(служба маршрутизації та віддаленого доступу) при конфігуруванні Windows 2003
server в якості маршрутизатора або сервера підключення на вимогу або
віддаленого доступу). p>
Служби, що запускаються в контексті облікового запису:
Деякі служби запускаються в контексті безпеки Local System, тому що
ця обліковий запис має необмежені локальні привілеї. І, навпаки, у
багатьох випадках обліковий запис Local System замінюється на Local Service або
Network Service. Обидві вони маю права, незначно перевищують ті, що дані
Аутентифіковані користувачам. Як випливає з її назви, обліковий запис
Local Service призначена для локальних системних служб (і не має
можливості автентифікувати в мережі), у той час як Network Service
призначається для служб, що вимагають мережевого доступу. (Вона імітує комп'ютерні
облікові записи при аутентифікації по мережі). p>
Аутентифікація p>
Удосконалення
механізмів аутентифікації застосовуються для проведення аутентифікації як у
локальних системах, так і в доменах Active Directory. p>
Настройки
аутентифікації в локальній системі за замовчуванням обмежують використання
локальних облікових записів з порожнім паролем тільки для роботи з консолі. Це
означає, що подібні облікові записи (без призначення пароля) не можуть використовуватися
для будь-якого іншого типу доступу, що виходить з віддалених систем (таких, як
підключення дисків або з'єднання "віддалений робочий стіл/віддалена
підтримка "). p>
Зміни
аутентифікації в Active Directory є більш помітними, коли маєш справу з
довірчими відносинами між деревами (cross-forest trust). Довірчі
відносини між деревами дозволяють створювати засновані на Kerberos
довірчі відносини між кореневими доменами лісів (що вимагає, щоб обидва
ліси перебували на функціональному рівні Windows 2003, що, у свою чергу,
має на увазі, що всі контролери доменів працюють під управлінням ОС Windows
2003 Server і всі домени є доменами функціонального рівня Windows
2003). P>
Подібні
довірчі відносини є транзитивних, що означає, що вони
поширюються на всі домени більш низького рівня в кожному з цих лісів. Це
дозволяє будь-якому користувачеві з одного лісу отримати захищений доступ до
будь-якого ресурсу, розташованому в іншому лісі, включаючи вхід в систему з іншого
лісу (використовуючи угоду про іменуванні UPN). При налаштуваннях за замовчуванням,
аутентифікація здійснюється в межах усього лісу, даючи всім учасникам
безпеки з інших лісів такі ж можливості доступу до локальних ресурсів,
що і у користувачів і комп'ютерів локального лісу. Але, в будь-якому випадку, доступ
користувачів до ресурсів залежать від дозволів, визначених на цих ресурсах. p>
Якщо
ви не відчуваєте себе на "короткій нозі" з подібним типом сценарію,
то можете налаштувати вибіркову аутентифікацію на основі довірчих відносин
рівня лісу, що вимагає функціонального рівня лісу Windows 2003. У цьому
випадку, ви можете позначити користувачів або групи облікових записів з
іншого лісу, яким дозволено автентифікувати, а також вибирати ресурси в
вашому лісі, до яких ці облікові записи будуть мати доступ. Цей процес
складається з двох основних етапів: p>
Перший етап включає в себе
призначення учасникам безпеки з іншого лісу дозволу "Allowed to
Authenticate "(допускається до автентифікації) для об'єкта Active Directory,
представляє обліковий запис комп'ютера, на якому міститься цей ресурс.
Наприклад, уявіть собі, що існують довірчі відносини між двома
лісами функціонального рівня Windows 2003 - ForestA і ForestB - налаштованих на
вибіркову аутентифікацію. Користувач UserA в домені DomainA лісу ForestA
повинен отримати доступ до загального ресурсу ShareB на ServerB в домені DomainB лісу
ForestB. Щоб досягти цього, повинна бути виконана наступна послідовність
кроків: p>
Адміністратор
DomainA створює глобальну групу (наприклад, GroupA) в DomainA і включаєте
користувача UserA в якості її члена. Ви можете також призначити
відповідні дозволи безпосередньо UserA (одним з переваг цього
підходу є прозорість), але робота з окремими для користувача
обліковими записами стає неефективною, якщо їх занадто багато. p>
Запускаєте оснащення Active Directory Users and Computers з фокусом на DomainB. Виділяєте
ServerB і виконуєте подвійне клацання миші на його зображенні, щоб викликати
діалогове вікно властивостей ServerB. p>
клацаєте
вкладку Security і додаєте DomainAGroupA до списку у верхній частині цього
діалогового вікна. У нижній частині активуєте вікно мітки в стовпці Allow для
дозволів "Allowed to Authenticate" і "Read". На цьому
перший крок завершено - тепер членам глобальної групи DomainAGroupA дозволено
автентифікувати при доступі до DomainBServerB. p>
На
другому етапі просто
призначте необхідний рівень прав для ресурсу ShareB на ServerB для глобальної
групи DomainAGroupA (в якості альтернативи можна додати глобальну групу
DomainAGroupA в локальну групу домену DomainB і встановити дозволи для цієї
локальної групи). Це може бути зроблено за допомогою стандартних методів (за допомогою
графічного інтерфейсу або інструментів командного рядка, наприклад, CACLS). p>
Межлесная
(cross-forest) аутентифікація може також здійснюватися для реєстраційних
імен користувачів через Internet Authentication Service (хоча в цьому випадку
потрібні двонаправлені довірчі відносини між лісами). p>
Список літератури h2>
Для
підготовки даної роботи були використані матеріали з сайту http://mdforum.dynu.com
p>