Рольова модель доступу в системах C2 для оборони: проектування та реалізація

Контроль доступу в оборонному програмному забезпеченні C2 — це не функція, яку додають наприкінці розробки. Це фундаментальне архітектурне рішення, що визначає, хто може бачити які дані, хто може видавати які команди, і як ці рішення застосовуються на кожному рівні системи — від API-ендпоінтів до запитів до бази даних та підписок на WebSocket. Помилка тут означає або розкриття секретних даних неавторизованим користувачам, або блокування операторів, яким потрібна ситуаційна обізнаність в реальному часі.

Стандартний контроль доступу на основі ролей (RBAC), реалізований у комерційних провайдерах ідентичності, достатньо покриває розподіл ролей та дозволів для корпоративного ПЗ. Системи C2 ЗСУ та МОУ вимагають додаткового виміру: рівнів таємності та відсіків. Користувач може бути автентифікований і мати правильну роль (наприклад, «оператор»), але все одно отримати відмову в доступі до конкретного треку, тому що цей трек позначений класифікацією або відсіком, допуску до якого у користувача немає. Це принцип «need-to-know» у технічному втіленні.

RBAC проти ABAC: яка модель підходить для C2 оборони

Чиста RBAC призначає дозволи ролям, а ролі — користувачам. Роль «офіцер S2 батальйону» надає доступ до розвідувальних шарів; роль «офіцер логістики» — до даних ланцюга постачання. Ця модель проста в реалізації та аудиті, але не може виразити тонкозернисті обмеження на рівні даних без вибуху ролей — створення окремої ролі для кожної можливої комбінації класифікацій.

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

На практиці системи C2 оборони використовують гібридний підхід: RBAC для грубозернистого застосування ролей (хто може отримати доступ до якого модуля застосунку) та ABAC для тонкозернистої фільтрації даних (які записи в межах модуля може бачити користувач).

Рівні таємності та відсіки

Рівні класифікації НАТО у зростаючому порядку: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET. Більшість тактичних систем C2 працюють на рівні SECRET або нижче. Рівень класифікації об'єкта даних — це мінімальний рівень допуску, необхідний для доступу до нього.

Відсіки ортогональні до рівнів класифікації. Користувач з допуском SECRET може не мати відсіку SIGINT або HUMINT, навіть на рівні SECRET. Трек, отриманий від датчика SIGINT, позначається відсіком SIGINT; лише користувачі з цим відсіком бачать трек у COP, незалежно від загального рівня їх допуску. В програмному забезпеченні відсіки реалізуються як набір рядкових тегів як на записі даних, так і в наборі атрибутів користувача; доступ надається лише тоді, коли набір відсіків запису даних є підмножиною набору відсіків користувача.

Структура JWT-претензій для C2 оборони

JSON Web Token несе ідентичність і претензії атрибутів користувача між провайдером ідентичності та сервісами застосунку C2. Структура JWT-корисного навантаження для оборонного застосунку:

{
  "sub": "user-uuid-1234",
  "name": "Кпт. О. Іваненко",
  "roles": ["operator", "s2-officer"],
  "clearance": "SECRET",
  "compartments": ["SIGINT", "HUMINT"],
  "unit": "1-32-МП",
  "network_segment": "SIPRNET",
  "iat": 1746960000,
  "exp": 1746963600,
  "jti": "unique-token-id"
}

Претензія clearance несе рівень допуску користувача як рядок, що відображається на числове значення в механізмі політики. Претензія compartments — це масив рядків відсіків. Претензія network_segment несе мережевий контекст, уможливлюючи рішення про доступ на основі середовища.

Терміни дії токенів для оборонних систем коротші, ніж комерційні норми: токени доступу на 60 хвилин з ротацією токенів оновлення. Кожне оновлення токена повторно перевіряє поточний стан атрибутів у провайдері ідентичності, забезпечуючи набуття чинності відкликаних допусків протягом одного циклу оновлення.

Точки застосування політики

У мікросервісній архітектурі C2 контроль доступу повинен застосовуватись на кількох рівнях — не лише на API-шлюзі.

API-шлюз (груба RBAC). Перевіряє підпис JWT та термін дії. Відхиляє запити з невалідними токенами. Не приймає рішень про доступ на рівні даних.

Сервісний рівень (оцінка політики ABAC). Кожен сервіс, що обробляє секретні дані, має вбудований засіб прийняття рішень про доступ. Перед поверненням об'єкта даних сервіс оцінює: допуск користувача >= рівень класифікації даних І відсіки користувача є надмножиною відсіків даних. Об'єкти, які не проходять цю перевірку, фільтруються з відповіді, а не повертаються з помилкою 403 — сам факт існування секретних записів часто є таємним.

Рівень бази даних (безпека на рівні рядків). Політики безпеки на рівні рядків (RLS) PostgreSQL застосовують обмеження на рівні даних безпосередньо в базі даних, забезпечуючи глибокий захист від помилок у логіці застосунку.

Модель багаторівневої безпеки Белла-Ла-Падула

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

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

Аудиторські журнали та інтеграція з SIEM

Кожне рішення про доступ — як надання, так і відмова — повинно реєструватись з достатньою деталізацією для перевірки безпеки та реагування на інциденти. Запис аудиторського журналу системи C2 для ЗСУ включає: мітку часу, ідентифікатор користувача, рівень допуску, спробовану дію, ідентифікатор ресурсу, рівень класифікації ресурсу, рішення (GRANT/DENY) та правило політики, що його виробило.

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