Вступ

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

У реєстрі зберігаються дані, що необхідні для правильного функціонування Windows. До них відносяться профілі усіх користувачів, відомості про встановлене програмне забезпечення та типи документів, що можуть бути створені кожною програмою, інформація про властивості папок та застосувань, а також встановлене обладнання та порти, що використовуються [1].

Стабільність системного реєстру та цілісність його вмісту є життєво важливими для функціонування ОС Windows.

Саме тому є актуальною задача дослідження питань контролю доступу до системного реєстру ОС Windows.

Моделі контролю доступу

На сьогоднішній день розроблено три загальних моделі контролю доступу:

• Примусовий контроль доступу (англ. Mandatory access aontrol, MAC);
• Дискреційний контроль доступу (англ. Discretionary access control, DAC);
• Керування доступом на основі ролей (англ. Role-based access control, RBAC).

Примусовий контроль доступу (англ. Mandatory Access Control, MAC)

Ця модель спочатку розроблялася для потреб армії та розвідки США [2]. Головне призначення - забезпечити захист секретної інформації від читання користувачем з недостатнім рівнем привілеїв.

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

Формально, будь-яка система контролю доступу, що характеризується цією властивістю, може вважатися системою примусового контролю доступу, але де-факто, під системою примусового контролю доступу розуміється система, що реалізує модель багаторівневої безпеки (англ. Multi-Level Security, MLS).

Відповідно до моделі багаторівневої безпеки, заздалегідь визначається упорядкований набір рівнів секретності (наприклад, можливі наступні рівні: "цілком секретно", "секретно", "для внутрішнього користування", "не секретно"). З цього набору кожному інформаційному об`єкту призначається класифікаційна мітка, а суб`єктам системи - рівні доступу.

Загальна ідея полягає у тому, що доступ до об`єкту заданого рівня секретності можуть мати лише суб`єкти з більшим чи рівним рівнем доступу. Але, навіть у межах єдиної моделі багаторівневої безпеки, деталі алгоритму визначення можливості доступу можуть різнитися в залежності від цілей системи. Тут можливі два майже діаметрально протилежних підходи - це модель Белла-Ла Падули та модель Біби.

Модель Белла-Ла Падули (David E. Bell, Leonard J. La Padula, 1973 [3,4]) призначена забезпечити конфіденційність даних. Модель описує проблему контролю доступу у термінах переходів між станами системи. Кожний стан описується сукупністю наявних звернень суб`єктів до об`єктів. Модель формулює правила, які гарантують, що з любого безпечного стану система може перейти лише до іншого безпечного стану.

Суть політики безпеки, що визначається моделлю, зводиться до двох простих правил:

• Правило простої властивості безпеки – суб`єкт може читати лише ті об`єкти, що мають рівень секретності менший або рівний рівню доступу суб`єкта. Це правило гарантує що користувачі з недостатніми повноваженнями не отримають доступ до конфіденційної інформації. Ця властивість також іноді формулюється як "заборона читання вгору".
• Правило *-властивості («зірочка»-властивості) – суб`єкт можеписати (дописувати) інформацію лише до тих об`єктів, що мають рівень секретності більший чи рівний рівню доступу суб'єкта. Це правило гарантує, що не трапиться витік конфіденційної інформації на нижні рівні секретності. Ця властивість також іноді формулюється як "заборона запису вниз".

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

На відміну від моделі Белла-Ла Падули, модель Біби (Kenneth J. Biba), що також відома як «модель цілісності Біби» (Biba Integrity Model), покликана забезпечити цілісність важливих даних [5].

У межах моделі Біби усі об'єкти та суб'єкти також класифікуються за заздалегідь визначеним набором рівнів, але у моделі Біби ці рівні мають інше семантичне значення - тут це рівні "цілісності" або "достовірності".

У відповідності до поставленої мети та семантики рівнів безпеки модель Біби встановлює правила, що є діаметрально протилежними до тих, що встановлюються моделлю Белла-Ла Падули:

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

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

Дискреційний контроль доступу (англ. Discretionary access control, DAC)

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

Саме тому виникає необхідність у більш гнучкій моделі контролю доступу. Такою моделлю є модель дискреційного контролю доступу. Суть дискреційності полягає у тому, що будь-який суб'єкт може за власним розсудом передати частину своїх прав на об'єкт будь-якому іншому суб'єкту [6].

Можливі декілька підходів до побудови дискреційного керування доступом:

• Кожний об'єкт системи має прив’язаного до нього суб'єкта, що називається його власником. Саме власник встановлює права доступу до об'єкта.
• Система має лише одного виділеного суб'єкта — суперкористувача, що має право встановлювати права володіння для усіх інших суб'єктів системи.
• Суб'єкт з певним правом може передати це право будь-якому іншому суб'єкту.

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

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

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

Подальший розвиток ідея груп користувачі отримала у моделі керування доступом на основі ролей, що буде розглянуто далі.                                                                          

Типовим представником реалізації DAC-моделі є механізм ACL (Access Control List), що застосовується у системах Windows сімейства NT [7]. У межах цього механізму, з кожним захищеним об'єктом асоціюється дескриптор безпеки (ACL-запис). У дескрипторі безпеки зберігається наступна інформація:

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

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

Право редагування дескриптора безпеки як окреме право доступу описується самим дескриптором. За замовчуванням цим правом володіють власних, системний обліковий запис та користувачі з групи «Адміністратори».

Параметри успадкування дескриптора визначають чи наслідує даний об'єкт свій дескриптор від батьківського об`єкту та чи буде дескриптор успадкований дочірніми об'єктами. За замовчуванням успадкування активно для більшості системних об'єктів. Тому нові створені дочірні об'єкти (файл у каталозі, підключ реєстру) успадковують дескриптор безпеки батьківського об'єкту.

Іншим прикладом реалізації DAC-моделі є система прав доступу, що є традиційною для UNIX-подібних систем [8,9]. Ця система має ряд принципових відмінностей від Windows ACL:

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

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

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

Керування доступом на основі ролей (англ. Role-base access control, RBAC)

Ця модель є новою та вельми перспективною альтернативою для MAC- и DAC-моделей. До розробки моделі керування доступом на основі ролей, MAC та DAC розглядалися як два виключно можливих варіанта системи контролю - якщо модель не була MAC-моделлю, то вона вважалася DAC-моделлю та навпаки. Але дослідження кінця 90-х показали, що модель RBAC не є ані MAC-моделлю, ані DAC-моделлю [10,11].

Для визначення моделі RBAC використовуються наступні терміни:

• U = Суб'єкт (англ. Subject) = Людина або автоматизований агент (множина користувачів);
• R = Роль (англ. Role) = Робоча функція або назва, що визначається на рівні авторизації (множина ролей);
• P = Дозволи (англ. Permissions) = Встановлення режиму доступу до ресурсу (множина прав доступу на об'єкти системи);
• S = Сесія (англ. Session) = Відповідність між U, R та/або P
• UA = Призначення суб'єкта (англ. Subject Assignment)
• PA: R -> 2^p — функція, що визначає для кожної ролі множину прав доступу; при цьому для кожного p ∈ P існує r ∈ R таке, що p ∈ PA(r); (англ. Permission Assignment)
• RH = Частково впорядкована ієрархія ролей (англ. Role Hierarchy).
• Один суб'єкт може мати декілька ролей.
• Одну роль можуть мати декілька суб'єктів.
• Одна роль може мати декілька дозволів.
• Один дозвіл може належати декільком ролям.
• Суб'єкт може мати декілька одночасних сесій з різними дозволами.

Привілеї не призначаються користувачам безпосередньо, а придбаються ними лише через свої ролі. Таким чином, керування індивідуальними правами користувача зводиться до призначення йому ролей. Це спрощує такі операції, як додання користувача або зміна підрозділу користувача.

При цьому призначення користувачам ролей та редагування дозволів для ролей може виконуватися лише вповноваженими органами (користувачами з адміністративними правами) та не доступно для рядових користувачів. У цьому сенсі RBAC-модель також має властивість мандатності.

На відміну від DAC-моделі, дозволи задаються не на режим доступу до об'єкту, а на транзакції з об'єктом. Це дозволяє описувати дозволи для складних операцій зі складеними даними.

Слід відмітити, що у RBAC-моделі операції редагування параметрів контролю доступу також є транзакціями, а тому контролюються самою системою.

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

Аналіз існуючого контролю доступу до реєстру ОС Windows

Стандартним засобом контролю доступу до реєстру ОС Windows є механізм ACL, що реалізує DAC-модель. Об'єктами, які знаходяться під захистом, є ключі реєстру. Окремі значення у ключі не існують як самостійні об'єкти та відповідно не можуть мати дескриптор безпеки.

Для кожного ключа визначено наступний набір можливих прав доступу:

• Запит значення
• Завдання значення
• Створення підрозділу
• Створення символічного посилання (не документована можливість).
• Перелік підрозділів
• Підпис на повідомлення
• Запис дозволів
• Читання дозволів
• Зміна власника

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

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

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

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

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

Для захисту системного реєстру Windows від атаки за одним з цих сценаріїв є доцільним запровадити механізм захисту, що доповнив би наявний механізм ACL.

Реалізовувати альтернативний механізм на базі DAC-моделі, фактично означає дублювати стандартний механізм захисту. Це тимчасово знизить вірогідність успішної атаки, але зрештою не вирішує вказані проблеми вразливості.

Таким чином перспективним є використання MAC-моделі або RBAC-моделі.

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

У межах RBAC-моделі особливий інтерес представляє опис прав доступу у термінах "розумних" транзакцій - тобто контроль не лише фактів доступу, а й вмісту даних, що обробляються.

Висновки

На сьогоднішній день розроблено три основні моделі контролю доступу – MAC-модель, DAC-модель та RBAC-модель. Для контролю доступу до реєстру Windows мають стандартні засоби, що реалізують DAC-модель. У межах DAC-моделі конфігурація наявних засобів контролю доступу є оптимальною для системи загального призначення та не потребує модифікацій. Але залишаються можливі сценарії атаки, які у межах DAC-моделі повністю виключити неможливо. Для захисту від цих атак є доцільним розробити альтернативний механізм захисту на базі MAC-моделі або RBAC-моделі, що доповнює можливості стандартного механізму контролю доступу до реєстру ОС Windows.

Список літератури

1. Сведения о реестре Windows для опытных пользователей. // Microsoft® Справка и поддержка.
   http://support.microsoft.com/kb/256986/ru
2. Mandatory access control // Wikipedia, the free encyclopedia. 2009.
   http://en.wikipedia.org/wiki/Mandatory_access_control
3. Bell, David Elliott and La Padula, Leonard J. Secure Computer Systems: Mathematical Foundations. MITRE Corporation. 1973.
   http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf
4. Bell, David Elliott and La Padula, Leonard J. Secure Computer System: Unified Exposition and Multics Interpretation. MITRE Corporation. 1976.
   http://csrc.nist.gov/publications/history/bell76.pdf
5. Biba, K. J. "Integrity Considerations for Secure Computer Systems". MITRE Corporation. 1975.
   http://seclab.cs.ucdavis.edu/projects/history/CD/biba75.pdf
6. Избирательное управление доступом  // Википедия — свободная энциклопедия. 2008.
   http://ru.wikipedia.org/wiki/Избирательное_управление_доступом
7. Access Control Lists // Microsoft Developer Network. 2009
   http://msdn.microsoft.com/en-us/library/aa374872(VS.85).aspx
8. UNIX File Permissions and POSIX ACLs // HP CIFS Server 3.0k Administrator's Guide version A.02.04: HP-UX 11i v1, HP-UX 11i v2, and HP-UX 11i v3.
   http://docs.hp.com/en/B8725-90143/ch03s02.html
9. POSIX Access Control Lists on Linux / Andreas Grünbacher. SuSE Labs. 2003
   http://www.suse.de/~agruen/acl/linux-acls/online/
10. D.F. Ferraiolo and D.R. Kuhn. "Role Based Access Control" 15th National Computer Security Conference, Oct 13-16, 1992, pp. 554-563.
    http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-92.pdf
11. National Institute of Standards and Technology FAQ on RBAC models and standards. 2007.
    http://csrc.nist.gov/groups/SNS/rbac/faq.html
12. Управление доступом в сложных информационных системах на основе ролевой авторизации / О.С. Бартунов, Е.Б. Родичев, С.Н. Ардатский, С.Н. Назин. 2003.
    http://www.sai.msu.su/~megera/wiki/Rbac-paper
13. Registry Key Security and Access Rights // Microsoft Developer Network. 2005
    http://msdn.microsoft.com/en-us/library/ms724878(VS.85).aspx