Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Безпека.docx
Скачиваний:
164
Добавлен:
31.08.2019
Размер:
6.2 Mб
Скачать

13.4. Аудит

Реєстрація подій у Windows здійснюється шляхом виклику функцій ядра ОС, що додають записи у файли з розширенням .evt, розміщені в каталозі \WINNT\ system32\config [107, 108]. С три журнали реєстрації подій — системний, прикладного ПЗ та безпеки. Події аудита генерує диспетчер об'єктів за результатами перевірки прав доступу. Для цього він використовує список аудита SACL, який визначає для кожного об'єкта, що саме буде реєструватися за спроби отримати доступ тим чи іншим суб'єктом. Події аудита можуть генерувати також Win32 функції, доступні прикладним програмам.

З аудитом пов'язані дві функції привілеїв: SeSecurityPrivilege і SeAudit- Privilege. Використовуючи першу, процес керує файлом журналу безпеки та переглядає і змінює SACL об'єктів, а за допомогою другої він генерує запис аудита у цьому журналі..

Рішення про аудит подій безпеки конкретного типу приймається відповідно до політики аудита локальної системи. Політика аудита є частиною політики без­пеки (Local Security Policy), яку підтримує підсистема Lsass у локальній системі. Під час ініціалізації системи та після змінення політики Lsass надсилає SRM повідомлення, що інформує його про поточну політику аудита. Lsass відповідає за отримання від SRM записів, що генеруються на основі подій аудита, а також за їх редагування та передавання реєстратору подій (Event Logger).

SRM надсилає записи аудита до Lsass через своє LPC- з'єднання, після чого Event Logger додає їх до журналу безпеки. Крім записів аудита, що передає SRM,

Записи аудита, що підлягають пересиланню LSA, ставляться у чергу в міру їх надходження — вони не передаються пакетами. Пересилання цих записів може здійснюватись у два способи. Якщо запис аудита невеликий (менший за LPC- повідомлення максимального розміру), він надсилається як LPC- повідомлення та копіюється з простору адрес SRM у простір адрес процесу Lsass. Якщо ж запис аудита великий, SRM робить його доступним для Lsass через спільну пам'ять та передає Lsass вказівник на нього у LPC-повідомленні.

У Windows 2000/ХР адміністратори можуть переглядати журнали реєстрації через Control Panel (у російській локалізації — Панель управления). Списки ауди­та об'єктів задають у діалоговому вікні Auditing (у російській локалізації — Парамет­ры аудита),яке можна відкрити за допомогою Windows Explorer(Properties► Security► Advanced► Auditing(Свойства► Безопасность► Дополнительно► Параметры аудита)).

Політику аудита задають окремо — за допомогою спеціального оснащення, до­ступного через стартове меню або Control Panel (Administrative tasks ► Local secu­rity policy (Администрирование ► Локальная политика безопасности)).

13.5. Аналіз причин уразливостей системи Windows

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

Рис. 13.4. Взаємодія елементів системи аудита

Lsass і SAM генерують власні записи аудита, які Lsass пересилає безпосередньо Event Logger. На рис. 13.4 зображено схему системи аудита.

Рис. 13.5. Причини вразливості Windows NT

Слід чітко розмежовувати операційні системи Windows сімейства NT та інші (незахищені) операційні системи компанії Майкрософт (MS-DOS, Windows 3.х, 95/98/ME). Фактично, в них немає нічого спільного, крім торговельної марки Windows. Наразі Майкрософт не підтримує застарілі версії ОС, які не належать до сімейства NT.

Необхідно визнати, що на початку використання Windows NT в Інтернеті було виявлено багато помилок і вад захисту, які поступово виправлялися в сервісних пакетах (Service Pack) [15, 60], яких для Windows NT 4.0 було випущено аж шість. Windows NT 5, відома як Windows 2000, виявилася більш досконалою. Що стосується клієнтської системи Windows ХР SP2 і серверної Windows 2003 Server, то до організації їх безпеки принципових зауважень немає.

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

Узагальнимо причини вразливості Windows і наведемо класифікацію, запропоновану в [15] (рис. 13.5).

Таку класифікацію застосовують не лише до Windows, а й до інших ОС.

Висновки

  1. Операційні системи сімейства Windows NT різних версій були сертифіковані за стандартами безпеки, зокрема за стандартом ISO/IEC 15408. ОС Windows XP SP2 у 2005 році пройшла експертне оцінювання на відповідність до вимог чинних в Україні нормативних документів щодо захищеності інформації від несанкціонованого доступу.

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

  3. КЗЗ Windows NT складається з таких основних компонентів:

  • монітор безпеки (Security Reference Monitor, SRM);

  • підсистема локальної автентифікації (Local Security Authentication Subsys­tem

Service, Lsass), що включає в себе сервіс локальної автентифікації Lsasrv;

  • база даних політики Lsass, розміщена в розділі реєстру HKLM\SECURITY;

  • диспетчер облікових записів безпеки (Security Account Manager, SAM) — служба, що виконується у процесі Lsass;

  • база даних SAM, розташована в розділі реєстру НKLM\SAM;

  • Active Directory;

  • пакети автентифікації;

  • процес Logon (Winlogon);

  • GINA (Graphical Identification and Authentication) — DLL режиму кори­стувача, що виконується у процесі Winlogon;

  • служба мережного входження до системи (Net Logon).

  1. Windows реалізує дискреційну модель розмежування доступу. Керування дос­тупом здійснюється за допомогою модуля SRM і реалізується викликом функ­ції SeAccessCheck ядра ОС за будь-якої спроби суб'єкта отримати доступ. При цьому використовуються дві структури даних — маркер доступу суб'єкта, що є носієм повноважень останнього, та дескриптор захисту об'єкта, що містить іден­тифікатори власника об'єкта та його первинної групи, список дискреційного контролю доступу (DACL) та список аудита (SACL). Матриця доступу в цій ОС зберігається у вигляді списків контролю доступу об'єктів.

  2. Windows підтримує такі типи суб'єктів доступу: користувачі (звичайні та псевдокористувачі), групи користувачів, спеціальні (тобто тимчасові) групи (на­приклад, INTERACTIVE і NETWORK), відносні суб'єкти (наприклад, CREA- TOROWNER).

  3. Усі об'єкти Windows є об'єктами доступу. Доступ суб'єкта до будь-якого об'єк­та ОС може бути обмежений. У Windows існує ієрархія типів об'єктів, причо­-

му операції, визначені для певного типу об'єктів, успадковуються об'єктами всіх підтипів цього типу. Файли, дискові каталоги та ключі реєстру — постійні об'єкти, які зберігаються на дисках комп'ютера. Решта об'єктів — тимчасові; вони зберігаються лише в оперативній пам'яті.

  1. Windows NT підтримує 22 методи доступу суб'єктів до об'єктів. Шість із них можуть використовувати об'єкти всіх типів; їх називають стандартними мсто дами доступу. Об'єкт кожного типу підтримує також до 16 типів специфічних методів доступу. З кожним із методів доступу пов'язане право доступу, яке так само може бути стандартним або специфічним.

  2. Підсистема автентифікації Windows має трирівневу архітектуру. На верхньому рівні знаходиться процес автентифікації WinLogon.exe. Більшість високорівневих функцій процесу автентифікації реалізуються бібліотеками-провайдерами. На середньому рівні головну роль відіграє локальний розпорядник безпеки LSA та пакети автентифікації — бібліотеки, що реалізують більшість низькорівневих функцій автентифікації. На нижньому рівні підсистеми автен­тифікації знаходяться сховища облікових записів користувачів (у стандартній конфігурації — база даних SAM і сервіс NetLogon).

  3. Реєстрація подій у Windows здійснюється шляхом виклику функцій ядра ОС. Події аудита може генерувати диспетчер об'єктів за результатами перевірки прав доступу, для чого він використовує список аудита, який називають сис­темним списком контролю доступу. Події аудита можуть генерувати й безпо­середньо Win32-функції, доступні прикладним програмам. Це саме право має код режиму ядра. Рішення про аудит конкретного типу подій безпеки прий­мається відповідно до політики аудита локальної системи. Політика аудита є складовою політики безпеки (Local Security Policy).

Контрольні запитання та завдання

    1. Які сучасні концепції застосовує архітектура Windows?

    2. Назвіть компоненти, з яких складається ядро Windows.

    3. Які компоненти входять до комплексу засобів захисту Windows? Яке призна­чення має кожен із компонентів?

    4. Які особливості архітектури Windows забезпечують легкість перенесення цієї операційної системи на інші апаратні платформи?

    5. Який компонент КЗЗ здійснює керування доступом у Windows?

    6. Яку модель розмежування доступу реалізує Windows?

    7. Які структури даних застосовуються під час перевірки спроби доступу суб'єк­та до об'єкта? Яке призначення кожної зі структур?

    8. Назвіть типи суб'єктів доступу, які підтримує ОС Windows.

    9. Які об'єкти, що їх підтримує ОС Windows, є постійними об'єктами? Чим вони відрізняються від тимчасових об'єктів?

10. Назвіть стандартні методи доступу до об'єктів у ОС Windows.

11. Що таке відображувані права доступу? Як їх застосовують під час перевірки прав

доступу?

12. Які компоненти КЗЗ операційної системи Windows забезпечують

автентифікацію користувачів?

13. Як здійснюється процес авторизації користувача в ОС Windows?

14. Які компоненти ОС Windows можуть генерувати події аудита?

15. Де і в якому вигляді зберігаються у Windows журнали аудита?

Розділ 286

Системи оброблення конфіденційної інформації

  • Застосування захищених операційних систем для створення систем оброблення конфіденційної інформації

  • Середовище Trusted Solaris

  • Керування доступом до прикладних програм

  • Операційна система Фенікс

  • Дискреційна модель ієрархічного керування