8.5. Керування доступом. Основні поняття

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

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

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

Таблиця 8.1. Фрагмент матриці доступу

	Файл	Програма	Лінія зв'язку	Реляційна таблиця
Користувач - 1	orw системної консолі	е	ГУ/ з 8:00 до 18:00
Користувач - 2				а
„о"- означає дозвіл на передачу прав доступу іншим користувачам „г"- читання, „%'"- запис, „є"- виконання, „а"- додавання інформації

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

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

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

При ухваленні рішення про надання доступу звичайно аналізується наступна інформація:

• ідентифікатор суб'єкта (ідентифікатор користувача, мережна адреса комп'ютера й т.п.). Подібні ідентифікатори є основою довільного (абодискреційного) керування доступом;

• атрибути суб'єкта (мітка безпеки, група користувача й т.п.). Мітки

безпеки - основа примусового (мандатного) керування доступом.

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

Списки доступу - винятково гнучкий засіб. З їхньою допомогою легко виконати вимогу про гранулярність прав з точністю до користувача. За допомогою списків нескладно додати права або явно заборонити доступ (наприклад, щоб покарати декількох членів групи користувачів). Безумовно, списки є кращим засобом довільного керування доступом.

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

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

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

Зручною надбудовою над засобами логічного керування доступом є обмежуючий інтерфейс, коли користувача позбавляють самої можливості спробувати зробити несанкціоновані дії, включивши в число видимих йому об'єктів тільки ті, до яких він має доступ. Подібний підхід звичайно реалізують у межах системи меню (користувачеві показують лише припустимі варіанти вибору) або за допомогою обмежуючих оболонок, таких як restricted shell в ОС Unix.

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