Управління доступом

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

Основні терміни та поняття, пов’язані з управлінням доступом, включають:

Принципи управління доступом встановлюють основні настанови та підходи до реалізації безпеки та ефективності управління доступом на платформі реєстрів.

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

Управління доступом на Платформі Реєстрів здійснюється за допомогою чотирьох ключових складових, а саме:

Зовнішній Identity Provider в Сервісі управління користувачами та ролями (Keycloak). Завдяки використанню ІСЕІ, кабінет надає можливість пройти e-ідентифікацію за допомогою електронних підписів (на файловому, хмарному чи інших захищених носіях, за допомогою MobileID) та BankID НБУ.

Розмежування прав доступу на платформі реалізовано на базі ролей. Ролі поділені на дав типи - системні та регламентні. Системні ролі з відповідними дозволами постачаються разом з платформою. Регламентні ролі спроектовані для досягнення гнучкості процесу розмежування прав та надання можливостей розробнику регламенту покрити всі необхідні потреби у різноманітних реєстрах.

Отримувач послуг:

Процес автентифікації отримувача послуг закінчується входом його у відповідний кабінет. Під час процесу первинної автентифікації громадянина відбувається створення його профілю в KeyCloak Realm та заповнення атрибутів зареєстрованого користувача інформацією отриманою з електронного підпису та даних отриманих у результаті інтеграції з ЄДР. Система автоматично присвоює одну з трьох системних ролей відповідно до атрибутів користувача:

unregistered_individual - фізична особа unregistered_entrepreneur - фоп або представник unregistered_legal - представник юридичної особи

Перелічені системні ролі надають отримувачу послуг доступ до своїх даних та до єдиного доступного бізнес-процесу - онбордингу. Як тільки користувач закінчує виконання онбордингу відбувається заміна тимчасової ролі з префіксом UNREGISTERED на відповідну постійну:

individual - фізична особа entrepreneur - фоп або представник legal - представник юридичної особи

Механізм надання доступу громадянину до бізнес процесів у кабінеті користувача базується саме на вказаних ролях. Саме розробник регламенту описує авторизаційні правила вказаних ролей до бізнес-процесів.

Надавач послуг:

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

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

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

Адміністратори:

При створенні адміністратора платформи або адміністратора реєстру за замовчування їм надається стандратна відповідна роль за принципами найменшого привілею (Principle of Least Privilege) та обмеженого доступу (Need-to-Know Principle) щоб вони отримали доступ лише до тієї інформації, яка необхідна для виконання їхніх обов’язків.

Далі додаткові ролі до платформенних та реєстрових адміністративних сервісів можуть бути додані через KeyCloak.

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

Платформа реєстрів надає можливість побудувати ієрархічну модель доступу до об’єктів даних відповідно до рівнів ієрархічної структури та ролей користувачів. Це дозволяє забезпечити контроль над доступом до об’єктів на основі їх ієрархічного положення та ролі користувача.

Ієрархічна модель складається з трьох основних частин:

Модель надає змогу розробникам регламенту спроектувати надання дозволів на доступ до даних реєстру враховуючи комплексність структури організації. Яскрави прикладом використання ієрархічної иоделі є побудова рольової модель за територіальною прив’язкою (КАТОТТГ)

За умови використання ієрархічної моделі ефективні права доступу до даних можна відобразити на наступній діаграмі.

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

Підсистема управління користувачами та ролями налаштована таким чином:

Усі адміністративні сервіси та кабінети користувачів викнують повний ланцюжок виходу при ініціювання події логаута. Збереження сесій також спроектовано надійно та безпечно. На стороні клієнту сесії зберігаються в coockie та сконфігуровні таким чином щоб передача відбувалась лише по захищеному каналу заязку задля захисту від перехоплення. Встановлено захист від несанкціонованого доступу клієнтськими скриптами, наприклад, JavaScript. Це зменшує ризик атак на перехоплення куків або XSS-атак. В додачу сконфігурований захист від CSRF-атак, що забезпечує, що кукі використовується лише на цільовому веб-сайті.

На стороні бекенду сесії користувачів зберігаютсья у Redis Sentinel.