EvchevDenis
commented
3 weeks ago Запитання №2
1) Приклади файлів, користувачів та можливих груп (ролей) користувачів
Файли або таблиці БД, які обробляє програмне забезпечення
- Файли ігрових рівнів у форматі .txt, які містять інформацію про об’єкти, їхні характеристики, позицію на рівні та інші параметри для побудови ігрових рівнів.
- Файли асетів у форматах .png, .jpeg, тощо, які використовуються як графічні ресурси, наприклад, текстури або фони для рівнів.
- Файли аудіо у форматах .wav, .mp3, або інших, які використовуються для звукових ефектів та музики в грі.
Типи користувачів або розробників, яким цікаво працювати з програмним забезпеченням
- Тестувальник гри – тестує функціональність гри, перевіряє роботу фізики об'єктів та взаємодію ігрових елементів.
- Дизайнер рівнів – створює ігрові рівні за допомогою інструментів Drag-and-Drop, налаштовує об’єкти, їхні параметри та розташування.
- Звуковий дизайнер – інтегрує та налаштовує аудіо-ефекти за допомогою інтерфейсу OpenAL для налаштування аудіо параметрів ігрових подій.
Можливі групи (ролі) користувачів
- Тестувальник гри – має доступ до тестування рівнів, можливість запускати гру в режимі тестування, але не може змінювати об’єкти або налаштування рівнів.
- Дизайнер рівнів – має доступ до редагування рівнів, додавання нових об'єктів, їхньої конфігурації, але обмежений у налаштуванні аудіо.
- Звуковий дизайнер – має доступ до налаштування та інтеграції аудіо, але обмежений у редагуванні рівнів.
2) Модель керування доступом та її реалізація
Ігровий рушій використовує модель RBAC для контролю доступу, оскільки кожна роль користувача (група) має чітко визначені функції та права. Ця модель дозволяє кожному користувачеві взаємодіяти лише з тією частиною рушія, яка відповідає його ролі. У самій програмі інтерфейс користувача адаптований під його роль – наприклад, тестувальник не бачить інструментів для редагування рівнів або налаштування аудіо, усе це забезпечено через перевірку спеціального файлу конфігурації, тобто для кожного користувача зберігається інформація про його роль у системі.
3) Рекомендації щодо зміни моделі керування доступом при значному зростанні кількості користувачів та ролей
Якщо кількість користувачів і ролей зросте у 100 разів, модель RBAC може стати менш ефективною через збільшення кількості ролей, що ускладнить керування доступом. В такому випадку можна запровадити створення підкатегорій в ролях, наприклад, розбиття на підгрупи всередині кожної основної ролі. Це знизить кількість операцій для управління доступом і спростить контроль на великому масштабі, наприклад тестувальник функціональності(тестування основних механік гри) та тестувальник продуктивності(тестування продуктивності гри, наприклад, вимірювати швидкість завантаження рівнів, стабільність кадрів). Також можна впровадити гібридну модель DAC/RBAC - це може забезпечити більшу гнучкість, дозволяючи окремим користувачам мати специфічні права доступу, які не залежать від ролі.
oleksandrblazhko
Запитання №1
За варіантом 7 маємо:
1) Використовуючи дані формули, обчислимо трудомісткість кожної моделі:
DAC (Discretionary Access Control)
Трудомісткість DAC=∣S∣×∣O∣=28×21=588 операцій
RBAC (Role-Based Access Control)
Трудомісткість RBAC=∣S∣×∣R∣+∣R∣×∣O∣=28×14+14×21=392+294=686 операцій
MAC (Mandatory Access Control)
Трудомісткість MAC=∣S∣+∣O∣=28+21=49 операцій
Висновки до 1 завдання: DAC має трудомісткість 588 операцій, що є середнім значенням порівняно з іншими моделями. RBAC з трудомісткістю 686 операцій є більш затратним через облік груп користувачів. MAC є найменш трудомістким із 49 операціями, оскільки ця модель не вимагає детального обліку взаємодій між користувачами та об'єктами доступу. Перехід від DAC до RBAC збільшує трудомісткість керування доступом, що не завжди доцільно при невеликій кількості користувачів та об'єктів, оскільки RBAC стає більш ефективним при значно більшій кількості користувачів. Перехід від RBAC до MAC є доцільним, оскільки MAC значно спрощує трудомісткість операцій і може бути кращим варіантом для великих обсягів даних та користувачів, де необхідний лише базовий рівень контролю.
2) Змінюємо початкові параметри:
DAC (Discretionary Access Control)
Трудомісткість DAC=∣S∣×∣O∣=56×21=1176 операцій
RBAC (Role-Based Access Control)
Трудомісткість RBAC=∣S∣×∣R∣+∣R∣×∣O∣=56×7+7×21=392+147=539 операцій
MAC (Mandatory Access Control)
Трудомісткість MAC=∣S∣+∣O∣=56+21=77 операцій
Висновки до 2 завдання: Для DAC трудомісткість значно зросла до 1176 операцій, що робить його менш ефективним для великої кількості користувачів. Трудомісткість RBAC знизилася до 539 операцій завдяки зменшенню кількості ролей. Це робить RBAC вигіднішою для таких умов, ніж DAC. MAC залишається найефективнішим із 77 операціями. Тому у нових умовах перехід від DAC до RBAC стає доцільним, оскільки RBAC є менш трудомістким і зручним для управління великою кількістю користувачів з меншою кількістю ролей. Перехід від RBAC до MAC залишається виправданим для зменшення трудомісткості, якщо можна використовувати більш спрощену модель керування доступом.