caramel2312
commented
5 days ago Запитання 2
Файли і таблиці БД, які обробляє програмне забезпечення
Таблиці бази даних:
- Users: зберігає інформацію про облікові записи користувачів (ID, ім'я, рівень доступу, прогрес у грі).
- GameInventory: містить дані про інвентар гравців (ID гравця, предмети, кількість).
- GameWorld: дані про об’єкти світу, їхні координати, статус (активний, знищений тощо).
- SaveFiles: дані про збереження прогресу гри (ID гравця, дата збереження, координати, параметри світу).
- NPCInteractions: лог взаємодії з NPC (ID гравця, ID NPC, тип взаємодії).
Файли:
- Конфігураційні файли для налаштувань гри (графіка, звуки тощо).
- Локальні збереження гри у форматах JSON або XML.
Можливі групи (ролі) користувачів
- Гравці — отримують доступ до основної функціональності гри: доступ до ігрових даних (інвентар, прогрес, взаємодії зі світом).
- Тестувальники — перевіряють стабільність гри, збереження даних та відновлення прогресу: доступ до розширеного логування, аналітики продуктивності.
- Розробники — використовують дані для діагностики помилок, аналізу продуктивності та покращення гри: доступ до системних файлів, але без права модифікувати ігрові дані.
- Адміністратори — керують доступом до системних файлів, оновленнями та конфігураціями: повний доступ до БД, системних файлів, можливість конфігурації.
Модель керування доступом: Role-Based Access Control (RBAC) і реалізація
У грі використовуються ролі (гравець, тестувальник, розробник, адміністратор), які мають різні рівні доступу. Наприклад: Гравці мають обмежений доступ до своїх даних. Тестувальники можуть переглядати логи гри, але не змінювати їх. Адміністратори мають найвищий рівень доступу, включаючи модифікацію БД.
Ідентифікація користувачів: кожен користувач має унікальний ID, що визначає його роль. Перевірка доступу: через таблицю доступу, яка зв’язує ID користувача з дозволами для конкретних операцій (CRUD). Програмна реалізація: у коді використовуються middleware для перевірки ролі користувача під час кожного запиту до API.
Рекомендації щодо зміни моделі керування доступом
Якщо кількість користувачів та можливих груп (ролей) у програмному забезпеченні зросте в 100 разів, існуюча модель RBAC може стати менш ефективною через збільшення складності управління ролями та пов’язаними з ними дозволами. У таких умовах необхідно оптимізувати поточну модель для забезпечення її стабільності та масштабованості.
Рекомендується вдосконалити RBAC, впровадивши ієрархію ролей, яка дозволить структурувати їх у вигляді дерева, де вищі ролі успадковуватимуть дозволи нижчих. Це суттєво зменшить кількість дублювання налаштувань і спростить управління доступом. Наприклад, загальні права доступу можна буде визначати на рівні базових ролей, а специфічні — додавати на вищих рівнях ієрархії.
Також, можливо перейти на атрибутивну модель керування доступом (ABAC), яка дозволяє надавати доступ не лише на основі ролей, а й враховує додаткові атрибути, такі як час доступу, геолокацію користувача, тип пристрою чи інші специфічні параметри. Це забезпечить більшу гнучкість у налаштуванні доступу та дозволить автоматизувати частину процесів. Як альтернативу, можна впровадити гібридну модель, яка поєднує RBAC та ABAC. Основою залишаються ролі, але атрибути додаються як додатковий рівень перевірки. Наприклад, навіть якщо користувач належить до певної ролі, доступ до ресурсу може бути обмежений у залежності від контексту, як-от робочий час чи конкретна IP-адреса.
oleksandrblazhko
Варіант 29
Запитання 1
Розрахунок трудомісткісті операцій керування доступом для DAC, RBAC, MAC моделей
Кількість таблиць |O|: 29 3 = 87; Кількість користувачів |S|: 29 4 = 116; Кількість груп (ролей) користувачів |R|: 29 * 2 = 58.
DAC
|S| |O| = 11687 = 10 092 операцій
RBAC
|S| |R| + |R| |O| = 11658 + 5887 = 11774 операцій
MAC
|S| + |O| = 116+87 = 203 операцій
Висновки
Аналізуючи результати розрахунків трудомісткості операцій для моделей керування доступом, отримуємо наступне:
Перехід від DAC до RBAC призводить до зростання трудомісткості. Це виправдано лише за наявності додаткових вимог до управління доступом, оскільки RBAC забезпечує більше структурованості за рахунок додаткових операцій.
Перехід від RBAC до MAC знижує трудомісткість, що демонструє ефективність MAC для зменшення обсягу операцій з керування доступом.
Отже, перехід від DAC до RBAC збільшує трудомісткість, а перехід від RBAC до MAC дає змогу суттєво її знизити.
Розрахунок трудомісткісті операцій керування доступом для DAC, RBAC, MAC моделей, збільшивши у 2 рази кількість користувачів, а кількість груп (ролей) зменшивши у 2 рази
Кількість таблиць |O|: 29 3 = 87; Кількість користувачів |S|: (29 4)2 = 232; Кількість груп (ролей) користувачів |R|: (29 2)/2 = 29.
DAC
|S| |O| = 232 87 = 20184 операцій
RBAC
|S| |R| + |R| |O| = 23229 + 2987 = 9251 операцій
MAC
|S| + |O| = 232+87 = 319 операцій
Висновки
DAC: Трудомісткість у нових умовах зросла вдвічі (з 10092 до 20184), оскільки кількість користувачів була збільшена у 2 рази, а кількість об'єктів залишилася незмінною. Залежність цієї моделі від кількості користувачів робить її значно менш ефективною у системах із великою кількістю користувачів.
RBAC: Трудомісткість у нових умовах знизилася (з 11774 до 9251). Це сталося завдяки зменшенню кількості груп (ролей) у 2 рази. Модель RBAC демонструє більшу стійкість до змін кількості користувачів за рахунок ролей, що спрощує керування доступом.
MAC: Трудомісткість збільшилася лише на 116 операцій (з 203 до 319), оскільки вона залежить лише від кількості користувачів і об'єктів, але не враховує зв’язки між ними. Приріст є незначним порівняно з іншими моделями.
Перехід від DAC до RBAC. У нових умовах перехід є доцільним, оскільки трудомісткість RBAC знизилася у порівнянні з DAC (9,251 проти 20,184). Зменшення кількості ролей зробило RBAC більш ефективною для систем із великою кількістю користувачів.
Перехід від RBAC до MAC також є доцільним, оскільки трудомісткість MAC у 29 разів менша за RBAC (319 проти 9,251). Проте цей перехід пов'язаний із суттєвою зміною підходу до управління доступом, тому може вимагати значних організаційних зусиль.
Таким чином, у нових умовах RBAC стає значно ефективнішою, але для досягнення максимальної оптимізації доцільно розглядати перехід до MAC.