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

13.3.4. Стандартні настроювання прав доступу

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

  • Administrators (у російській локалізації системи — администраторы) — ко­ристувачі з цієї групи мають повний набір прав на локальному комп'ютері чи в домені.

  • Users (у російській локалізації — пользователи) — за умови, що нову копію Windows встановлено в розділі NTFS, стандартне настроювання системи без пеки таке, що користувачі з групи Users не можуть порушувати цілісність oпeраційної системи і встановлених програм. Користувачі з цієї групи не мають повноважень на встановлення програм, які б могли використовувати інші члени групи (у такий спосіб здійснюють захист від «троянських коней»). Користувачі не можуть також отримати доступ до даних інших користувачів.

  • Power Users (у російській локалізації — опытные пользователи). Ця група має менше прав, ніж група Administrators, але набагато більше, ніж група Users. Зокрема, користувачі з цієї групи, на відміну від користувачів із групи Users, мають право на записування в підкаталоги Program Files, що дає їм змогу інсталювати деякі програми. У системі Windows ХР Home Edition ця група

відсутня.

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

Після встановлення пакетів поновлень (Service Pack) параметри безпеки мо­жуть змінитися — як правило, захищеність системи зростає. Проте може виник­нути проблема сумісності з раніше встановленим прикладним ПЗ, через що деякі програми можуть навіть припинити своє функціонування.

13.3.5. Ідентифікація й автентифікація

Підсистема автентифікації Windows має трирівневу архітектуру (рис. 13.3).

Рис. 13.3. Архітектура підсистеми автентифікації Windows NT

На верхньому рівні підсистеми автентифікації функціонує процес автенти­фікації WinLogon.exe, який є звичайним процесом Win32, що виконується від імені псевдокористувача SYSTEM. Процес автоматично запускається під час старту операційної системи і залишається активним доти, доки не буде вимкнено жив­лення комп'ютера чи перезавантажено операційну систему. У випадку аварійного завершення WinLogon здійснюється примусове аварійне завершення роботи всієї ОС (стан, відомий як «синій екран»). Більшість високорівневих функцій процесу автентифікації реалізують бібліотеки-провайдери (на кшталт msgina.dll — провай­дер локального входження у систему). Якщо у системі встановлено програмне за­безпечення, що підтримує входження користувачів із віддалених терміналів (на­приклад, сервер Telnet), то це програмне забезпечення має зареєструвати свого провайдера.

Нa середньому рінні головну роль виконують локальний розпорядник безпеки (Local Security Authority, LSA) і так звані пакети автентифікації бібліотеки, що реалізують більшість низькорівневих функцій автентифікації. LSA викону ється в процесі Lsass.exe, подібно до WinLogon, у режимі користувача і від імені псевдокористувача SYSTEM. Як і WinLogon, LSA передовіряє більшість своїх функцій бібліотекам. Стандартну схему автентифікації реалізує пакет MSV (біб ліотека msvl_0.dll).

На нижньому рівні підсистеми автентифікації знаходяться сховища облікових записів користувачів, зокрема еталонні образи паролів. У стандартній конфігурації ОС нижній рівень підсистеми автентифікації містить базу даних SAM і сервіс NetLogon: першу використовують для отримання даних з реєстру локального комп'ютера, а другу — з контролера домену.

Усі зазначені компоненти було описано вище, в підрозділі 13.2.2. Вхід користувача до системи здійснюється таким чином.

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

  2. Провайдер здійснює автентифікацію, передаючи інформацію, що ідентифікує та автентифікує користувача, на середній рівень. Для цього використовується системний виклик LogonUser.

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

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

  5. Якщо паролі збігаються, LSA отримує з нижнього рівня інформацію про те, чи може цей користувач негайно розпочати роботу з системою (чи не застарілий пароль, чи не заблоковано обліковий запис користувача тощо).

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

  7. Якщо маркер доступу було створено успішно, провайдер здійснює авториза­цію користувача. Для цього він запускає процес Userlnit.exe від імені користувача, якого щойно було автентифіковано.

  8. Процес Userlnit завантажує індивідуальні настроювання користувача, монтує його ключ реєстру і завантажує програмне середовище (Windows Explorer). Як бачимо, архітектура підсистеми авторизації досить гнучка і дає змогу ви­користовувати будь-які способи перевірки істинності. Зауважте, що WinLogon, запускаючи процес Userlnit, використовує привілеї псевдокористувача SYSTEM Якщо псевдокористувач SYSTEM не матиме привілеїв запускати процес від імені іншого користувача, користувачі не зможуть входити у систему.

Образи паролів зберігаються в спеціальному розділі реєстру, при цьому вико­ристовуються дві хеш-функції: MD4 (NT-hash) та менш криптостійка на основі DES (остання для сумісності з клієнтами попередньої серверної операційної сис­теми від Майкрософт — LAN Manager). Особливістю системи є те, що автори­зацію користувача можна проводити локально і делегувати контролерові домену.

Система керування обліковими записами локальних користувачів і групами у Windows має широкі можливості. Зокрема, для кожного користувача можна за­дати низку атрибутів, на кшталт належності до певної групи, місцезнаходження профілю користувача (User Profile), повноважень на доступ по комутованих ліні­ях тощо. Крім того, можна задати політику керування обліковими записами, що регламентує:

  • мінімальний та максимальний терміни існування пароля;

  • мінімальну довжину пароля;

  • унікальність пароля;

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

♦ тривалість блокування облікового запису.

Інтерфейс керування обліковими записами також дає змогу призначати кори­стувачам привілеї (права на всю систему, а не на конкретний об'єкт, наприклад, право входити в систему локально або змінювати системний час) та задавати політику аудита.