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

Нарешті, призначення прав доступу до окремих властивостей являє собою найвищий рівень деталізування, застосовний до всіх об'єктів Active Directory.

Контейнерні об'єкти в каталозі також підтримують детализація доступу, регламентуючи, хто має право створювати дочірні об'єкти і якого типу. Наприклад, правило доступу, визначене на рівні організаційної одиниці, може визначати, хто має право створювати об'єкти типу User (користувачі) в цьому контейнері. Інше правило в цієї ж OU може визначати, хто має право створювати об'єкти типу Printer.

Успадкування прав доступу

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

У Windows NT реалізована статична форма успадкування прав доступу, іноді також звана успадкуванням в момент створення. Інформація про управління доступом до контейнера розповсюджується на всі вкладені об'єкти контейнера. При створенні нового об'єкта успадковані права зливаються з правами доступу, що призначаються за умовчанням. Будь-які зміни успадкованих прав доступу, дерева, що виконуються надалі на вищих рівнях, повинні розповсюджуватися на всі дочірні об'єкти. Нові успадковані права доступу розповсюджуються на об'єкти Active Directory відповідно до того, як ці нові права визначені. Статична модель успадкування дозволяє збільшити продуктивність.

Аудит

Аудит одне з засобів захисту мережі Windows NT. З його допомогою можна відстежувати дії користувачів і ряд системних подій в мережі. Фіксуються наступні параметри, що стосуються дій, що здійснюються користувачами:

• виконана дія;

• ім'я користувача, що виконав дію;

• дата і час виконання.

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

У мережах з мінімальним вимогам до безпеки піддавайте аудиту:

• успішне використання ресурсів, тільки в тому випадку, якщо ця інформація вам необхідна для планування;

• успішне використання важливої і конфіденційної інформації.

У мережах зі середніми вимогами до безпеки піддавайте аудиту:

• успішне використання важливих ресурсів;

• вдалі і невдалі спроби зміни стратегії безпеки і адміністративної політики;

• успішне використання важливої і конфіденційної інформації.

У мережах з високими вимогами до безпеки піддавайте аудиту:

• вдалі і невдалі спроби реєстрації користувачів;

• вдале і невдале використання будь-яких ресурсів;

• вдалі і невдалі спроби зміни стратегії безпеки і адміністративної політики.

Аудит приводить до додаткового навантаження на систему, тому реєструйте лише події, що дійсно представляють інтерес.

Windows NT записує події в три журнали:

• Системний журнал (system log) містить повідомлення про помилки, попередження і іншу інформацію, вихідну від операційної системи і компонентів сторонніх виробників. Список подій, що реєструються в цьому журналі, приречений операційною системою і компонентами сторонніх виробників і не може бути змінений користувачем. Журнал знаходиться в файлі Sysevent.evt.

• Журнал безпеки (Security Log) містить інформацію про успішні і невдалі спроби виконання дій, що реєструються засобами аудиту. Події, що реєструються в цьому журналі, визначаються заданою вами стратегією аудиту. Журнал знаходиться в файлі Secevent.evt.

• Журнал додатків (Application Log) містить повідомлення про помилки, попередження і іншу інформацію, що видається різними додатками. Список подій, що реєструються в цьому журналі, визначається розробниками додатків. Журнал знаходиться в файлі Appevent.evt.

Всі журнали розміщені в папці %Systemroot%\System32\Config

ЕЛЕМЕНТИ БЕЗПЕКИ СИСТЕМИ Windows NT

Облікові записи користувачів і груп

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

Так само, як і в попередніх версіях Windows NT, у версії 5.0 є декілька вбудованих облікових записів користувачів і груп. Ці облікові записи наділені певними повноваженнями і можуть використовуватися як основа для нових облікових записів,

До вбудованих облікових записів користувачів відносяться:

• Guest обліковий запис, фіксуючий мінімальні привілеї гостя;

• Administrator вбудований обліковий запис для користувачів, наділених максимальними привілеями;

• Krbtgt вбудований обліковий запис, що використовується при початковій аутентификація Kerberos.

Крім них є два приховані вбудовані облікові записи:

• System обліковий запис, що використовується операційною системою;

• Creator owner творець (файла або каталога).

Перерахуємо вбудовані групи:

• локальні (залишені для сумісності)

Account operators;

Administrators;

Backup operators;

Guests;

Print operators;

Replicator;

Server operators;

Users;

• і глобальні

Domain guests гості домена;

Domain Users користувачі домена;

Domain Admins адміністратори домена.

Крім цих вбудованих груп є ще ряд спеціальних груп:

• Everyone в цю групу за умовчанням включаються взагалі всі користувачі в системі;

• Authenticated users в цю групу включаються тільки аутентифицированние користувачі домена;

• Self сам об'єкт.

Домени Windows NT

Управління доменами здійснюється за допомогою адміністративної консолі DNS. Ви можете визначити зони, прописати повністю певні імена, включити в домени комп'ютери і т. п.

Як вже вказувалося, домени об'єднуються в дерева. Для перегляду дерева доменів використовується спеціальний зліпок консолі управління (domain.msc), званий Domain Tree Management.

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

Як вже вказувалося, ці довірчі відносини є значення задавати лише тоді, коли двостороннє транзитивне довір'я Kerberos, що встановлюється за умовчанням, не відповідає безпеці; а також у разі зв'язку між кореневими доменами дерев в лісі.

Домени можуть працювати в двох режимах: «рідному» (native) і змішаному (mixed). При роботі в змішаному режимі в домен можуть входити як контроллери доменів, на яких встановлена версія Windows NT 5.0, так і з більш ранніми версіями.

«Рідний» режим роботи допускає включення в домен тільки контроллерів домена з Windows NT 5.0. У цьому режимі з'являється можливість створення вкладених груп, а також междоменного членства в групі.

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

Оскільки домен є контейнерним об'єктом каталога Active Directory, до нього застосовні ті ж самі види доступу, що і до будь-якого контейнера: повний доступ, читання, запис, створення і видалення дочірніх об'єктів.

Локальна політика безпеки

Локальна політика безпеки регламентує правила безпеки на локальному комп'ютері. З її допомогою можна розподілити адміністративні ролі, конкретизувати привілеї користувачів, призначити правила аудиту.

У порівнянні з можливостями аудиту, що були в Windows NT 4.0, в нової версії ОС доданий аудит ще двох категорій подій. Це специфічні події, пов'язані з доступом до служби каталогів Active Directory, і події, що відносяться до аутентификація Kerberos. Доступний роздільний аудит успішних і неуспішних подій.

Доменна політика

Доменна політика встановлює правила для всіх облікових записів в домені, торкаючись такі сфери, як правила паролів, блокування облікових записів, вибір уповноважених безпеці, Kerberos-правила і т. д. В першої бети-версії реалізовані тільки правила паролів і блокування облікових записів. По своїх можливостях вони практично не відрізняються від правил попередньої версії Windows NT.

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

Якщо адміністратор задав параметр Password never expires для конкретного користувача, той може не міняти пароль. Але така практика рекомендується тільки для службових облікових записів, від імені яких виконуються сервіси в системі.

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

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

Мінімальний період для дозволу зміни пароля варіюється в межах від 1 до 999 днів. За умовчанням він не обмежується. Звичайно, досить встановити 14 днів.

Редактор конфігурацій безпеки

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