МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «ЛЬВІВСЬКА ПОЛІТЕХНІКА»
Кафедра «Захист інформації»
/
ЗВІТ
До виконання практичної роботи № 2
«Мандатні політики інформаційної безпеки. Реалізація політики Белла-Лападули»
з курсу:
«Менеджмент інформаційної безпеки»
Мета роботи – практичне засвоєння студентами механізму реалізації мандатних політик інформаційної безпеки в інформаційних системах на прикладі моделі Белла-Лападули. Познайомитися з проблемою системи Z.
Теоретичні відомості
Основу мандатної політики безпеки складає мандатне управління доступом, яке передбачає, що:
усі суб’єкти та об’єкти повинні бути ідентифіковані;
задано лінійно упорядкований набір міток обмеження доступу;
кожному об’єкту ІС привласнена мітка обмеження доступу, яка визначає цінність інформації, яка міститься в ньому;
кожному суб’єкту ІС привласнена мітка обмеження доступу, яка визначає рівень довіри до нього – його рівень доступу;
рішення про дозвіл доступу суб’єкта до об’єкта приймається виходячи із типу доступу і порівняння мітки суб’єкта й об’єкта.
Найчастіше мандатну політику безпеки описують в термінах моделі Белла-Лападула.
1. Вихідна мандатна політика інформаційної безпеки
Нехай в інформаційній системі (ІС) визначено множину суб’єктів доступу S Si i n 1, { } і множину об’єктів доступу O Oj j m 1, { } . Вихідна мандатна політика управління доступом (Mandatory Access) в ІС системі базується на таких групах аксіом:
1. Вводиться множина атрибутів безпеки A, елементи якої впорядковані за допомогою встановленого відношення домінування. Наприклад, для України характерне використання такої множини рівнів безпеки A={відкрито (В), конфіденційно (К), таємно (Т), цілком таємно (ЦТ), особливої важливості (ОВ)}.
2. Кожному об’єкту ІС Оj O ставиться у відповідність атрибут безпеки x A Oj , який відповідає цінності об’єкта Oj і називається його рівнем (грифом) конфіденційності.
3. Кожному суб’єкту комп’ютерної системи Si >S ставиться у відповідність атрибут безпеки x A Si , який називається рівнем допуску суб’єкта і дорівнює максимальному з рівнів конфіденційності об’єктів, до якого суб’єкт Si буде мати допуск.
4. Якщо суб’єкт Si має рівень допуску xSi , а об’єкт Oj має рівень конфіденційності xOj , тоді Si буде мати допуск до Oj тоді і тільки тоді, коли xSi > xOj .
Незважаючи на переваги моделі Белла-Лападули, при її строгій реалізації в реальних ІС виникає декілька проблем:
1. Завищення рівня обмеження доступу, що пов’язано з однорівневою природою об’єктів і правилом безпеки щодо запису. Якщо суб’єкт з високим рівнем доступу хоче записати щось в об’єкт з низьким рівнем обмеження доступу, тоді спочатку доводиться підвищити рівень
обмеження доступу об’єкта, а тоді здійснювати запис. Таким чином, навіть одне речення, додане у великий документ суб’єктом з високим рівнем доступу, підвищує рівень обмеження доступу всього цього документа. Якщо в процесі роботи роботи зміни в документ вносять
суб’єкти з більшими рівнями доступу, рівень обмеження доступу документу також постійно зростає.
2. Запис наосліп. Ця проблема виникає, коли суб’єкт здійснює операцію запису в об’єкт з більш високим рівнем обмеження доступу, ніж його власний. У цьому випадку, після завершення операції запису, суб’єкт не зможе перевірити правильність виконання запису за допомогою контрольного читання, оскільки йому це заборонено відповідно до правила безпеки з читання.
3. Проблема віддаленого читання-запису. У розподілених системах при віддаленому читанні файлу створюються два потоки: від суб’єкта до об’єкта (запити на читання, підтвердження, інша службова інформація) і від об’єкта до суб’єкта (самі дані). При цьому, можлива ситуація, коли перший потік буде суперечити властивості безпеки по запису. На практиці для вирішення цієї проблеми необхідно розмежовувати службові потоки (запити, підтвердження) і саме передавання інформації.
4. Довірені суб’єкти. Модель Белла-Лападула не враховує, що в реальній ІС, як правило, існують суб’єкти, які діють в інтересах адміністратора, а також системні процеси, наприклад, драйвери. Жорстке дотримання правил заборони читання з верхнього рівня і заборони запису на нижній рівень в деяких випадках унеможливлює роботу таких процесів.
Основним же недоліком вихідної мандатної політики інформаційної безпеки (ІБ) є можливість витоку інформації «зверху вниз», наприклад, за допомогою реалізації «троянських коней», що запускаються з максимальними правами та, які здатні записувати інформацію на нижні рівні, звідки до неї можуть отримати доступ користувачі з меншими правами. Представлений недолік частково вирішується в політиці безпеки Белла-ЛаПадула.
2. Мандатна модель політики інформаційної безпеки Белла-Лападули
Мандатна модель політики ІБ Белла-Лападули базується на 2-ох властивостях. Перша властивість аналогічна вихідній мандатній моделі політики ІБ. Властивість NRU (not read up) – «відсутність читання вгору», свідчить, що суб’єкт Si , що має рівень допуску xSi , може читати інформацію з об’єкта Oj з рівнем безпеки xOj , лише якщо xOj ≤ xSi . Друга властивість моделі Белла-Лападули дає змогу частково вирішити проблему витоку інформації «зверху вниз». Властивість (NWD) (not write down) – «відсутність запису вниз», свідчить, що суб’єкт Si , що має рівень допуску xSi , може записувати інформацію в об’єкт Oj з рівнем безпеки xOj , лише якщо xOj ≥ xSi . Введення властивості NWD вирішує проблему троянських коней, оскільки запис інформації на нижчий рівень ІБ, типовий для троянських коней, заборонена. У політиці Белла-ЛаПадула суб’єкт може знизити свій рівень допуску за власним бажанням, а також підвищити його до початкового йому призначеного дміністратором ІС.
ЗАВДАННЯ ДО ПРАКТИЧНОЇ РОБОТИ
Здійснити реалізацію та дослідження політики безпеки Белла-Лападули. Номер варіанту завдання відповідає порядковому номеру студента в журналі викладача.
Нехай множина можливих операцій суб’єктів S над об’єктами O задана в такій формі: {«READ (доступ з читання)», «WRITE (доступ із запису)», «CHANGE (зміна рівня доступу суб’єкта)»}. Нехай множина атрибутів безпеки A задана у вигляді A={NONCONFIDENTIAL, CONFIDENTIAL, SECRET, TOP SECRET}.
Необхідно:
1. Отримайти з Додатку А інформацію про кількість суб’єктів та об’єктів комп’ютерної системи відповідно до варіанту.
2. Реалізувати програмний модуль (на будь-якій мові програмування), що реалізує політику інформаційної безпеки Белла-Лападули.
2.1. Обрати ідентифікатори користувачів, які будуть використовуватися при їх вході в комп’ютерну систему (за одним ідентифікатором для кожного користувача, кількість користувачів визначається відповідно до варіанту). Наприклад, множина з 3-ох ідентифікаторів користувачів {Admin, User1, User2}. Один із даних ідентифікаторів повинен відповідати адміністратору комп’ютерної системи, що має максимальні права доступу.
2.2. Випадковим чином надати об’єктам комп’ютерної системи рівні конфіденційності з множини A.
2.3. Випадковим чином надати суб’єктам комп’ютерної системи рівні допуску з множини A. Врахувати, що один з даних суб’єктів буде адміністратором, що має максимальний рівень допуску.
3. Реалізувати програмний модуль (на будь-якій мові програмування), що демонструє роботу користувача в комп’ютерній системі із мандатною моделлю політики ІБ. Даний модуль повинен виконувати такі функції:
3.1. при запуску модуля – виводити на екран сформовану модель Белла- Лападули – рівні конфіденційності об’єктів і рівні допуску суб’єктів.
3.2. запит ідентифікатора користувача (повинна проводитися його ідентифікація). У випадку успішної ідентифікації користувача повинен здійснюватися вхід в систему, в іншому випадку – виводити відповідне повідомлення.
3.3. За результатами ідентифікації суб’єкта після входу в систему, програма повинна чекати вказівок користувача на здійснення дій над об’єктами в комп’ютерній системі. Після отримання команди від користувача, на екран повинне виводитися повідомлення про успішність або невдачу операції. При виконанні операції зміни рівня доступу суб’єкта (change) даний рівень повинен модифікуватися. Повинна підтримуватися операція виходу з системи (exit), після якої, на екран знову повинна виводитися інформація про рівні доступу суб’єктів і рівні конфіденційності об’єктів і реалізовуватися запит для іншого ідентифікатора користувача. Діалог можна організувати, наприклад, таким чином (для вище побудованого прикладу моделі Белла-Лападули):
4. Протестувати реалізовану модель політики ІБ Белла-Лападули в різних ситуаціях і продемонструвати її викладачеві.
5. Продемонструвати можливість реалізації системи Z в розробленій моделі Белла-Лападули.
6. Оформити звіт згідно вимог (приклад оформлення титульної сторінки наведено в додатку В).
№ Варіанту
Кількість суб’єктів
Кількість об’єктів
3
5
4
Лістинг розробленої програми
Клас доступу
#ifndef MATRIX_ACCESS_H
#define MATRIX_ACCESS_H
#include "defines.h"
class CMandatAccess
{
//methods
public:
CMandatAccess();
~CMandatAccess();
void Run(); //Run UI and process
//private:
void MakeRandomAccesses(); //set random values
//UI
void ShowAccesses();
void ShowSavedAccesses();
void ShowUserNames(); //Show users names
void ErrorMessage(); //Error message
bool ShowResult( OBJECTS obj , USER_ACTION action); //Show result of access to object operation
//interactive
SUBJECTS getUser(); //Get user
USER_ACTION getUserAction(); //Get user action (what to do)
ACCESS getChangeOperation();
OBJECTS getObject(); //Get object (to do something with)
ACCESS getChangeAction(); //delegate action (delegate rights)
void changeAccess();
private:
ACCESS m_SubjectAccess[SUBJECT_COUNT];
ACCESS m_ObjectConfident[OBJECT_COUNT];
ACCESS m_SavedSubjectAccess[SUBJECT_COUNT];
ACCESS m_SavedObjectConfident[OBJECT_COUNT];
SUBJECTS m_User;
};
#endif /*MATRIX_ACCESS_H*/
Основна програма
#ifndef DEFINES_H
#define DEFINES_H
#include <iostream>
#include <ctime>
using namespace std;
enum OPERATIONS
{
OPERATION_READ,
OPERATION_WRITE,
OPERATION_CHANGE
};
enum ACCESS {
ACCESS_FIRST,
NONCONFIDENTIAL = ACCESS_FIRST,
CONFIDENTIAL,
SECRET,
TOP_SECRET,
ACCESS_LAST = TOP_SECRET
};
enum SUBJECTS
{
SUBJECT_FIRST,
ADMINISTRATOR = SUBJECT_FIRST,
USER_1,
USER_2,
GUEST_1,
SUBJECT_LAST = GUEST_1
};
enum OBJECTS
{
OBJECT_FIRST,
FDD = OBJECT_FIRST,
CD_ROM,
FILE1_DAT,
FILE2_TXT,
OBJECT_LAST = FILE2_TXT
};
enum USER_ACTION{USERACTION_FIRST, USERACTION_QUIT = USERACTION_FIRST, USERACTION_LOGOUT, USERACTION_READ, USERACTION_WRITE, USERACTION_CHANGE, USERACTION_LAST = USERACTION_CHANGE};
enum PERMISSION_ACTION{PERMISSION_ACTION_DELEGATE = 1, PERMISSION_ACTION_WRITE = 2, PERMISSION_ACTION_READ = 4};
enum DELEGATION_ACTION{DELEGATIONACTION_READ, DELEGATIONACTION_WRITE, DELEGATIONACTION_DELEGATE};
#define SUBJECT_COUNT ( SUBJECT_LAST+1 ) //count of users (subjects)
#define OBJECT_COUNT ( OBJECT_LAST + 1 ) //count of files (objects)
const char gUserNames[SUBJECT_COUNT][7] = {
"Admin", //admin
"User_1", //user 1
"User_2", //user 2
"Guest"}; //guest
const char gObjectNames[OBJECT_COUNT][10] = {
"FDD",
"CD_ROM",
"File1.dat",
"File2.txt",
};
const char gMandatAccesses[4][17] = {
"NON_CONFIDENTIAL",
"CONFIDENTIAL",
"SECRET",
"TOPSECRET"
};
const char gUserActions[6][8] = {
"quit",
"log out",
"read",
"write",
"change"
};
#define MAXBUFFER_SIZE 32
#endif DEFINES_H
Формалізація моделі Белла-Лападули
Об’єкти
Рівень доступу
Admin
Особливої важливості
User_1
Таємно
User_2
Цілком таємно
Guest
Відкрито
Суб’єкти
FDD
Відкрито
CD-ROM
Конвіденційно
File_1
Таємно
File_2
Конвіденційно
Результат виконання програми
Рис. 2 Користувач Admin
Рис. 3 Користувач Guest
Рис.4 Користувач Guest
Висновки
На даній лабораторній роботі я ознайомився з мандатною моделлю політики безпеки та з моделлю Белла-Лападули зокрема, та навчився використовувати їх на практиці.