Лабораторна робота

з предмету «Архітектура та моделі безпеки»

Тема: «Реалізація мандатної моделі політики безпеки (MAC)»

Підготував
Студент КБ 3.02
Черняк Павло
Перевірив: Кірєєв І.А.

1. Мандатна модель управління доступом(MAC)

2. Обмеження та властивості
3. Проектування застосунку з підтримкою MAC
4. Класифікація модулів за режимом обробки MAC

Мандатна модель управління доступом (Mandatory Access Control, MAC) - спосіб

розмежування доступу з фіксованим набором повноважень. Зазвичай справжній MAC
використовується в системах із підвищеними вимогами до безпеки і стоїть на службі
всіляких силових відомств і організацій, пов'язаних із державною або службовою
таємницею.
Абстрактна модель безпеки, що реалізується в класичному MAC (яким його знають
співробітники силових відомств), має такий вигляд (класична картинка, що ілюструє модель
Белла - Лападули):
 Модель MAC за своєю суттю є "електронною" реалізацією паперового "секретного"
документообігу. У MAC є такі "дійові особи":
- Ієрархія рівнів доступу, які обробляються в системі (зазвичай реєструються в ОС).
Для зручності часто задається у вигляді беззнакових чисел (від 0 до значення, обмеженого
реалізацією). У цьому разі для порівняння рівнів доступу (вищий/нижчий/рівний)
використовуються найпростіші арифметичні операції (дорівнює, менше, більше).
- Об'єкт з рівнем секретності. Будь-який файл, каталог у файловій системі, осередок
або запис у таблиці БД, таблиця в БД, сама БД, мережевий пакет тощо. Об'єкту присвоюється
будь-яке значення з ієрархії рівнів доступу. Для об'єкта допускається підвищення рівня
секретності (зміна до більшого значення рівня, ніж поточний). Зниження рівня секретності
категорично не допускається (хоча цілком можна реалізувати за допомогою певних
хитрощів).
- Суб'єкт із рівнем доступу. Процес будь-якого додатка або сеанс користувача (по суті
теж процес додатка). Мітка рівня доступу успадковується від суб'єкта всіма створюваними
даним суб'єктом об'єктами.
Значення рівня доступу суб'єкта або рівня секретності об'єкта зазвичай називають
терміном "мандатний рівень", "мандатна мітка" або просто "мітка" (у STCSEC цей термін
називається "hierarchical classification level"). Просто, ємко і майже однозначно.
Перевірка повноважень здійснюється при кожному факті доступу суб'єкта до об'єкта,
що захищається MAC. При цьому мандатна модель управління доступом зазвичай
використовується спільно з іншими механізмами контролю доступу, наприклад, DAC (UNIX-
моделлю і POSIX ACL). При цьому MAC перевіряється в останню чергу. Спершу
перевіряється доступ за DAC (як найменш захищений), а потім уже MAC.

Під час перевірки правомочності доступу суб'єкта до об'єкта згідно з мандатною

моделлю можливі такі комбінації:
1. Мандатна мітка суб'єкта дорівнює мандатній мітці об'єкта. У цьому разі
суб'єкту дозволено читати і змінювати об'єкт.
2. Мандатна мітка суб'єкта вища за мандатну мітку об'єкта. Суб'єкту дозволено
тільки читати об'єкт: він його бачить, але не може змінити.
3 Мандатна мітка суб'єкта нижче мандатної мітки об'єкта. Суб'єкту формально
дозволено створити об'єкт із вищою мандатною міткою (так зване "підвищення рівня
секретності об'єкта"). На практиці у суб'єкта немає технічної можливості для виконання цієї
операції (він просто "не бачить" об'єкт, що змінюється, наприклад, файл або каталог із
файлами).
Також у MAC існує таке поняття, як "категорія" (у термінології STCSEC цей термін
називається "non-hierarchical categories"). Категорії в MAC є опціональними до застосування.
У практиці реалізації MAC категорії використовуються для "горизонтального" розмежування
доступу між різними підрозділами організації. У цьому разі співробітники, незважаючи на
один мандатний рівень, отримуватимуть доступ тільки до тих категорій об'єктів, до яких для
них відкрито доступ згідно з їхньою міткою.

Обмеження та вразливості
MAC має свої обмеження та особливості:
 1. Користувачі системи не можуть самостійно визначати доступ суб'єктів до
об'єктів. З усього арсеналу управління доступом до об'єкта в MAC є тільки мандатна мітка і
мандатна категорія, які прив'язані до цього об'єкта. Управління доступом суб'єктів до
об'єктів здійснюють тільки адміністратори.
2. Якщо користувач хоче змінити мандатну мітку об'єкта, автором якого він є, то
йому необхідно перейти в сеанс цільової мітки. Пов'язано з тим, що користувач не може
вказати мітку за своїм бажанням, а може лише передати мітку об'єкту "у спадок". Одночасно
користувач може працювати тільки в сеансі однієї мандатної мітки.
3) Оскільки MAC використовується спільно з іншими моделями управління доступом,
виникають колізії: іноді не так просто з'ясувати, в якому "шарі" системи безпеки сталася
відмова в наданні доступу. Потрібен тонкий "тюнінг" усіх шарів захисту.
4. Крім самого налаштування доступу за допомогою інструментарію MAC
потрібна наявність регламенту безпеки. У ньому має бути описано, що означають конкретні
значення мандатних міток (це знаходиться за межами MAC), які об'єкти як захищаються, які
суб'єкти мають право на доступ. Без наявності узгодженого регламенту MAC сама по собі не
дасть security enhancement.
5. Використання MAC у розподіленій мережевій інфраструктурі. Традиційний
підхід до налаштування MAC - локально, вручну, за допомогою адміністратора відповідно до
інструкції. Є рішення, що дають змогу реалізувати централізовано кероване сховище MAC
(на кшталт ALD), але вони мають свої особливості та складнощі побудови.

Проектування застосунку з підтримкою MAC

Незважаючи на всі обмеження моделі, для тих, хто працює з держсектором, а
особливо із силовими відомствами, питання побудови застосунків із підтримкою мандатної
моделі управління доступом актуальне як ніколи. Раптом завтра саме вам доведеться
підтримувати MAC у своєму продукті?

На перший погляд здається, що модель примітивна і її реалізація проста як п'ять

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

Для того щоб додаток міг скористатися механізмом мандатних міток операційної
системи, мають бути виконані такі умови:
- Користувачі програми мають бути зареєстровані в сховищі користувачів операційної
системи. Щонайменше має бути якийсь ідентифікатор, що дає змогу однозначно зіставити
користувача програми з користувачем операційної системи (зазвичай це логін).
- Користувачам застосунку на рівні механізму MAC операційної системи мають бути
налаштовані мандатні дозволи на певні мандатні мітки (діапазони мандатних міток).

З погляду десктопного застосунку сценарій роботи користувача має такий вигляд:

 1. Користувач входить в ОС під своєю особистою УЗ у режимі необхідної йому
мітки. Запускає застосунок. Процес програми успадковує мандатну мітку.
2. Застосунок взаємодіє з БД на PostgreSQL, відображаючи користувачеві,
приміром, тільки записи таблиць БД із поточною мандатною міткою.

З погляду серверного додатка, що надає веб-сервіси, сценарій роботи користувача

концептуально близький, хоча й має трохи складніший вигляд:
1. Користувач входить в ОС під своєю особистою УЗ у режимі необхідної йому
мітки. Запускає браузер із підтримкою MAC, у нашому прикладі - Mozilla Firefox
("звичайний" браузер для цих цілей не підійде). Процес браузера успадковує мандатну мітку.
2. Користувач запитує адресу ресурсу додатка з підтримкою мандатних міток.
Браузер формує запит, додаючи в нього мандатну мітку.
3. Запит обробляє веб-сервер із підтримкою мандатних міток, у нашому прикладі
- Apache Http Server. Веб-сервер (процес якого працює в режимі мінімальної мандатної
мітки) зчитує мандатну мітку запиту, знаходить застосунок-обробник, запускає його процес
із переданою мандатною міткою.
4. Додаток взаємодіє з БД на PostgreSQL, ретранслюючи в запитах мандатну
мітку.

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

Це та сама інфраструктура, абстрагуватися від якої дуже складно, а часом неможливо.

Тому застосунок слід розбити на модулі, а вже за кожним модулем провести аналіз потреби в
підтримці MAC. Можливо, саме у вашому випадку достатньо підтримати MAC тільки в
одному модулі, і немає сенсу через цей модуль ускладнювати весь застосунок?
У разі, якщо ми розглядаємо якийсь абстрактний модуль (або весь застосунок, якщо
поділ застосунку на модулі не потрібен) можливі такі парадигми:
- Мінімальна мітка. Модуль обробляє дані в режимі мінімальної мандатної мітки
(мінімальна мітка, в якій функціонують процеси ОС - наприклад, 0 мандатна мітка) або без
мандатної мітки.
- Одна мітка. Модуль працює з даними тільки однієї мандатної мітки, що вища за
мінімальну мандатну мітку (будь-яку мітку, відмінну від тієї, в якій функціонують процеси
ОС).
- Кілька міток. Модуль працює з даними одразу кількох мандатних міток (як мітки, у
якій функціонують процеси ОС, так і інших міток, відмінних від мітки процесів ОС).
Модулям додатка з різними парадигмами обробки мандатних міток не варто знати
один про одного занадто багато. Інакше це загрожує виникненням великих і
непередбачуваних проблем у частині конфліктів доступу до різних об'єктів тощо. Ідея
мінімальної зв'язності для модулів очевидна. У разі роботи з MAC слід проявляти особливу
пильність і стежити за всіма "зв'язками" модулів.
 Далі розглянемо докладніше особливості проектування за трьох парадигм обробки
мандатних міток. Для цього ми накидали класифікацію від простого випадку до складного.
Ця класифікація має суто практичний і прикладний характер. Вона виходить з інтуїтивно
відчутних відмінностей під час розроблення тих чи інших модулів, а на практиці показала
свою дієвість.

Класифікація модулів за режимами обробки MAC

Режим мінімальної мандатної мітки
Мотивація для реалізації цього механізму в модулі:
- Модуль обробляє інформацію, яка в принципі не може оброблятися в системі з
іншими мандатними мітками, і не вимагає особливих привілеїв для читання/запису.
- Модуль сильно пов'язаний з інфраструктурою ОС, яка обмежує його
функціонування в режимі мандатної мітки, відмінної від мінімальної.
Модуль, що функціонує в цьому режимі, має перевіряти мандатну мітку процесу.
Якщо мітка процесу, в якому виконується цей модуль, відрізняється від мінімальної
(наприклад, не дорівнює 0 мандатній мітці), виконання всіх операцій (окрім перегляду) має
бути заборонене на рівні бізнес-логіки застосунку. Тобто ми можемо просто не пустити
користувача до використання цього модуля, якщо він прийшов до нас у сеансі мандатної
мітки, відмінної від нульової.

Приклади практичних кейсів, для яких підходить використання режиму мінімальної

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

Режим однієї мандатної мітки

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

Цей кейс може бути корисним у таких випадках:

- Було допущено помилку в архітектурі під час проєктування модуля (не було
закладено особливостей опрацювання записів у MAC), і немає ні часу, ні ресурсів усе
переписувати.
- Підтримка мандатної моделі управління доступом вводиться в уже функціонуючий
застосунок, і відповідно до вимог необхідно забезпечити роботу з міткою, вищою за
мінімальну в ОС. Так, це той самий випадок, коли до вас приходить керівник і повідомляє з
радістю, що ми виграли конкурс і будемо впроваджувати наше рішення в "найменування
секретного відомства"!
- Немає доцільності в реалізації повної підтримки одночасного опрацювання записів
кількох мандатних міток. Немає необхідності в одночасному опрацюванні записів одразу
декількох мандатних міток.
- Додаток функціонує в однокористувацькому режимі.

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

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

Приклади практичних кейсів, для яких підходить використання режиму однієї

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

Режим декількох мандатних міток

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