Моделі управління доступом

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

При цьому визначення понять «об'єкт» і «суб'єкт» можуть істотно відрізнятися. Ми будемо мати на увазі, що об'єкти є деякими контейнерами з інформацією, а суб'єкти - користувачі, які виконують різні операції над цими об'єктами.

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

Можна виділити три основні моделі управління доступом до об'єктів: мандатну, дискреционную і рольову.

3.1. мандатна модель

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

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

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

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

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

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

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

В основі мандатної управління доступом лежить мандатна модель безпеки Белла-ЛаПадули. Ця модель ґрунтується на правилах секретного документообігу застосовуються в багатьох країнах. На відміну від дискреційного управління, в якому користувачам безпосередньо прописуються права на читання, запис і виконання, в мандатної моделі управління доступом відбувається неявним чином. Всім користувачам (суб'єктам) і файлів (об'єктів) призначаються рівні доступу. Наприклад, «секретно», «совершенно секретно». Приклад ієрархії рівнів доступу:

3.2. Дискреційна модель

У дискреційної моделі безпеки управління доступом здійснюється шляхом

явною видачі повноважень на проведення дій з кожним із об'єктів системи. Наприклад, в моделі Харрісона-Руззо-Ульмана для цього служить матриця доступу, в якій визначені права доступу суб'єктів системи до об'єктів. Рядки матриці відповідають суб'єктам, а стовпці Об'єктив. Кожна клітинка матриці містить набір прав, які відповідний суб'єкт має по відношенню до відповідного об'єкту.

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

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

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

3.3. рольова модель

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

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

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

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