Модуль  контролю доступу та  базової безпеки в HR-системі військового  обліку

Кєрнус, Дмитро  Олександрович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9687
Title:	Модуль контролю доступу та базової безпеки в HR-системі військового обліку
Authors:	Оксамитна, Любов Павлівна Кєрнус, Дмитро Олександрович
Keywords:	КОНТРОЛЬ ДОСТУПУ;БАЗОВА БЕЗПЕКА;HR-СИСТЕМА;ВІЙСЬКОВИЙ ОБЛІК;АУДИТ ПОДІЙ;АВТЕНТИФІКАЦІЯ;АВТОРИЗАЦІЯ;REST API.
Issue Date:	10-Jun-2026
Abstract:	В умовах цифрової трансформації та підвищених вимог до захисту персональних даних особливої важливості набуває безпека HR-систем військового обліку. Обробка відомостей про військовозобов’язаних потребує надійного контролю доступу, розмежування повноважень користувачів, захисту API та фіксації дій у журналі аудиту. Впровадження модуля контролю доступу та базової безпеки дає змогу мінімізувати ризики несанкціонованого доступу, забезпечити цілісність даних і підвищити керованість процесів кадрового обліку. Метою кваліфікаційної роботи бакалавра є проєктування та програмна реалізація модуля контролю доступу і базової безпеки в HR-системі військового обліку, який забезпечує захищений доступ до функціоналу системи, контроль виконання критичних операцій та простежуваність дій користувачів. Основні положення і результати кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції «День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна. Практичне значення отриманих результатів полягає в підвищенні захищеності доступу до персональних та службових даних, забезпеченні керованого розмежування повноважень користувачів, підвищенні прозорості та відтворюваності дій у системі за рахунок аудиту подій, а також у формуванні основи для подальшого розвитку безпекових механізмів HR-системи військового обліку.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9687
Appears in Collections:	122 Комп’ютерні науки (Комп’ютерні науки та прикладне програмування)
Files in This Item:
File	Description	Size	Format
Пояснювальна записка_Кєрнус Дмитро_КН-2201_2025-2026.pdf Restricted Access		1.81 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра комп’ютерних наук та системного аналізу 
Пояснювальна записка 
до кваліфікаційної роботи 
бакалавра 
(освітньо-кваліфікаційний рівень) 
на тему: «Модуль контролю доступу та базової безпеки в HR-системі 
військового обліку» 
Виконав: студент 4 курсу, групи КН – 2201 
Спеціальності 122  «Комп’ютерні науки» 
(шифр і назва спеціальності) 
Освітня програма «Комп’ютерні науки та 
(назва освітньої програми) 
прикладне програмування» 
Дмитро КЄРНУС 
Керівник  Любов ОКСАМИТНА 
(ім’я та прізвище) 
Рецензент  Сергій СТАСЬ 
(ім’я та прізвище) 
Черкаси 2026 року 
Бланк завдання на кваліфікаційну роботу бакалавра студенту 
Черкаський державний технологічний університет 
Факультет Інформаційних технологій і систем 
Кафедра Комп’ютерних наук та системного аналізу 
Освітньо-кваліфікаційний рівень Бакалавр 
Спеціальність  122  –  Комп’ютерні науки 
Освітня програма Комп’ютерні науки та прикладне програмування 
ЗАТВЕРДЖУЮ 
Завідувач кафедри КНСА 
Юрій ТРИУС 
« »  2026 р. 
ЗАВДАННЯ 
на кваліфікаційну роботу бакалавра студенту 
Кєрнусу Дмитру Олександровичу 
(прізвище, ім‘я, по батькові) 
1. Тема роботи    Модуль контролю доступу та базової безпеки в HR-системі  військового обліку
Керівник роботи Оксамитна Л.П., к.т.н., доцент 
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання) 
затверджені наказом університету від «12» березня 2026 р. №56/03-03. 
2. Строк подання студентом роботи «  08  »   червня 20 26 року.
3. Вихідні дані до роботи:
Практичні навички роботи з інформаційними ресурсами. Робота з базами даних. 
Звіт з виробничої практики. Звіт з переддипломної практики. 
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ 
4.1. Теоретико-аналітичні засади контролю доступу та базової безпеки в HR-системі  військового   
обліку. 
4.2. Проєктування модуля контролю доступу та базової безпеки в HR-системі  військового обліку.  
4.3. Програмна реалізація модуля контролю доступу та базової безпеки. 
Висновки. 
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482. ЧДТУ. 62289-01. 
5.2. Додаток Б. Текст програми. 
5.3. Додаток В. Інструкція користувача. 
5.4. Додаток Г. Апробація результатів кваліфікаційної роботи бакалавра. 
5.5. Презентація у вигляді 22 слайдів. 
6. Консультанти розділів роботи 
 
Прізвище, ініціали та Підпис, дата 
Розділ посада 
консультанта завдання видав завдання прийняв 
    
    
 
7. Дата видачі завдання 12.01.2026 р. 
 
КАЛЕНДАРНИЙ ПЛАН 
№ з/п Назва етапів кваліфікаційної роботи бакалавра Строк виконання 
етапів роботи Примітка 
1 Видача завдання на кваліфікаційну роботу 
бакалавра. 12.01.2026 Виконано 
2 Аналіз літературних джерел, об’єкту та предмету 
дослідження. до 08.02.2026 Виконано 
3 Написання теоретичного розділу кваліфікаційної 
роботи бакалавра. до 23.03.2026 Виконано 
4 Написання аналітичного розділу (аналіз об’єкту 
й предмету дослідження). до 06.04.2026 Виконано 
5 Написання практичних розділів й висновків по 
роботі. до 15.05.2026 Виконано 
6 Передзахист кваліфікаційної роботи бакалавра 
на засіданні кафедри КНСА. 20.05.2026 Виконано 
7 Подання роботи завідувачу кафедри КНСА. до 10.06.2026 Виконано 
8 Захист кваліфікаційної роботи бакалавра. 10.06.2026 Виконано 
    
    
    
 
Студент   Дмитро КЄРНУС 
(підпис) 
 
 
Керівник роботи   Любов ОКСАМИТНА 
(підпис) 
4 
РЕФЕРАТ 
Кваліфікаційна робота бакалавра містить: 86 с., 16 рис., 3 таблиці, 13 
використаних джерел, 4 додатки. 
Актуальність теми. В умовах цифрової трансформації та підвищених вимог до 
захисту персональних даних особливої важливості набуває безпека HR-систем 
військового обліку. Обробка відомостей про військовозобов’язаних потребує 
надійного контролю доступу, розмежування повноважень користувачів, захисту API 
та фіксації дій у журналі аудиту. Впровадження модуля контролю доступу та базової 
безпеки дає змогу мінімізувати ризики несанкціонованого доступу, забезпечити 
цілісність даних і підвищити керованість процесів кадрового обліку. 
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра є 
проєктування та програмна реалізація модуля контролю доступу і базової безпеки в 
HR-системі  військового обліку, який забезпечує захищений доступ до функціоналу 
системи, контроль виконання критичних операцій та простежуваність дій 
користувачів. 
Завдання кваліфікаційної роботи бакалавра: 
– провести аналіз предметної області HR-системи військового обліку та 
визначити ключові ризики інформаційної безпеки; 
– проаналізувати сучасні підходи до автентифікації, авторизації, рольового 
розмежування доступу й аудиту подій; 
– обґрунтувати архітектурні принципи побудови модуля контролю доступу в 
клієнт-серверній системі; 
– реалізувати механізми безпечного входу, перевірки токенів та захисту API – 
запитів; 
– реалізувати модуль безпеки API та систему аудиту подій (Audit Log) із 
коректною обробкою помилок безпеки; 
– реалізувати базовий аудит дій користувачів і подій безпеки; 
– забезпечити узгодження безпекового контуру серверної і клієнтської частин; 
– виконати перевірку працездатності реалізованих рішень на тестових 
5 
сценаріях. 
Об’єкт дослідження: процеси організації доступу до даних і функціональних 
можливостей HR-системи військового обліку. 
Предмет дослідження: методи, моделі та програмні засоби реалізації 
контролю доступу і базової безпеки в клієнт-серверній HR-системі військового 
обліку. 
Методи дослідження: системний аналіз предметної області, аналіз сучасних 
підходів і стандартів інформаційної безпеки, моделювання ролей і політик доступу, 
методи проєктування програмних систем, а також методи прикладної реалізації та 
тестування програмного забезпечення. 
Апробація результатів роботи. Основні положення і результати 
кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції 
«День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна. 
Публікації. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л. 
П. Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована HR-
система закладу вищої освіти  : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.]; 
Міністерство освіти і науки України, Черкаський державний технологічний ун-т.  
Черкаси : ЧДТУ, 2026. С. 14. 
Практичне значення отриманих результатів полягає в підвищенні 
захищеності доступу до персональних та службових даних, забезпеченні керованого 
розмежування повноважень користувачів, підвищенні прозорості та відтворюваності 
дій у системі за рахунок аудиту подій, а також у формуванні основи для подальшого 
розвитку безпекових механізмів HR-системи військового обліку. 
Ключові слова: КОНТРОЛЬ ДОСТУПУ, БАЗОВА БЕЗПЕКА, HR-СИСТЕМА, 
ВІЙСЬКОВИЙ ОБЛІК, JWT, RBAC, АУДИТ ПОДІЙ, АВТЕНТИФІКАЦІЯ, 
АВТОРИЗАЦІЯ, REST API. 
ABSTRACT 
The bachelor’s qualification thesis consists of: 86 pages, 16 illustrations, 3 tables, 
13 references, and 4 appendices. 
6 
Relevance of the topic. In the context of digital transformation and increased 
requirements for the protection of personal data, the security of HR systems for military 
accounting is of particular importance. Processing information about military-liable persons 
requires reliable access control, user privilege management, API protection, and event 
logging in an audit journal. 
Purpose and objectives of the research. The purpose of the bachelor’s qualification 
work is to design and implement a software module for access control and basic security in 
the HR system for military accounting, which ensures secure access to system functionality, 
control over the execution of critical operations, and traceability of user actions. 
The tasks of the bachelor’s qualification work: 
– conduct an analysis of the HR system for military accounting domain and identify 
key information security risks; 
– analyze modern approaches to authentication, authorization, role-based access 
control, and event auditing; 
– substantiate the architectural principles for building an access control module in a 
client-server system; 
– implement mechanisms for secure login, token verification, and API request 
protection; 
– implement the API security module and event audit system (Audit Log) with 
proper security error handling; 
– implement basic auditing of user actions and security events; 
– ensure coordination of the security perimeter between server and client parts; 
– perform verification of the implemented solutions on test scenarios. 
Object of study: processes of organizing access to data and functional capabilities of 
the HR system for military accounting. 
Subject of the study: methods, models, and software tools for implementing access 
control and basic security in a client-server HR system for military accounting. 
Research methods include system analysis of the subject area, analysis of modern 
approaches and information security standards, role and access policy modeling, software 
system design methods, as well as methods of applied implementation and software testing. 
7 
Approbation of the results of the work. The main provisions and results of the 
bachelor’s qualification work were reported and discussed at the conference "Day of Student 
Science of the Department of KNSA", April 22, 2026, Cherkasy, Ukraine. 
Publications. Yu. O. Blagovisny, D. R. Holub, V. V. Dubrovny, D. O. Kjernus, L. P. 
Oksamytna, A. P. Sinkovskiy, V. V. Oleksiuk. Automated HR information system of a 
higher education institution : Collection of abstracts from the Cherkasy State Technological 
University Student Scientific and Practical Conference: 22–23 April 2026 / [edited by I. V. 
Melnyk]; Ministry of Education and Science of Ukraine, Cherkasy State Technological 
University.  Cherkasy : Cherkasy State Technological University, 2026. p. 14. 
The practical significance of the results obtained lies in enhancing the security of 
access to personal and official data, ensuring controlled differentiation of user privileges, 
improving transparency and reproducibility of actions in the system through event auditing, 
and forming the basis for further development of security mechanisms in the HR system for 
military accounting. 
Keywords: ACCESS CONTROL, BASIC SECURITY, HR SYSTEM, MILITARY 
ACCOUNTING, JWT, RBAC, EVENT AUDIT, AUTHENTICATION, 
AUTHORIZATION, REST API. 
  
8 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ ...... 10 
ВСТУП ................................................................................................................................ 11 
1 ТЕОРЕТИКО-АНАЛІТИЧНІ ЗАСАДИ КОНТРОЛЮ ДОСТУПУ ТА БАЗОВОЇ 
БЕЗПЕКИ В HR-СИСТЕМІ  ВІЙСЬКОВОГО ОБЛІКУ ................................................ 17 
1.1 Предметна область HR-систем и військового обліку та постановка проблеми 
безпеки ................................................................................................................................ 17 
1.1.1 Особливості процесів військового обліку в HR-системі та склад критичних 
даних. .................................................................................................................................. 19 
1.1.2 Ключові загрози інформаційній безпеці та вимоги до захисту доступу. ... 21 
1.2 Аналіз сучасних підходів і рішень для забезпечення контролю доступу ......... 24 
1.2.1 Моделі автентифікації та авторизації в інформаційних системах (RBAC, 
JWT, рольові політики).. ................................................................................................... 25 
1.2.2 Порівняльний аналіз існуючих підходів і обґрунтування вибору для HR-
системи військового обліку. ............................................................................................. 27 
1.3 Обґрунтування напрямів реалізації модуля контролю доступу та базової 
безпеки в проєкті ............................................................................................................... 30 
1.3.1 Функціональні та нефункціональні вимоги до модуля контролю оступу.. 30 
1.3.2 Логіка реалізації безпекового контуру в архітектурі проєкту.. ................... 32 
Висновки до розділу 1 .................................................................................................. 34 
2 ПРОЄКТУВАННЯ МОДУЛЯ КОНТРОЛЮ ДОСТУПУ ТА БАЗОВОЇ БЕЗПЕКИ В 
HR-СИСТЕМІ  ВІЙСЬКОВОГО ОБЛІКУ ...................................................................... 36 
2.1 Постановка задачі проєктування безпекового контуру ...................................... 36 
2.1.1 Цілі, межі та критерії успішності проєктування. .......................................... 37 
2.1.2 Функціональні сценарії та обмеження предметної області. ........................ 39 
2.2 Проєктування архітектури модуля контролю доступу ....................................... 41 
2.2.1 Архітектура взаємодії клієнтської та серверної частин. .............................. 41 
2.2.2 Логіка автентифікації, авторизації та захисту API. ...................................... 43 
2.3 Проєктування моделей доступу, станів і контрактів ........................................... 44 
9 
2.3.1 Рольова модель доступу та матриця прав. .................................................... 45 
2.3.2 Модель аудиту подій та журналювання безпекових операцій. ................... 47 
2.3.3 Проєктування API-контрактів і обробки помилок безпеки. ........................ 48 
Висновки до розділу 2 .................................................................................................. 50 
3 ПРОГРАМНА РЕАЛІЗАЦІЯ МОДУЛЯ КОНТРОЛЮ ДОСТУПУ ТА БАЗОВОЇ 
БЕЗПЕКИ............................................................................................................................ 51 
3.1 Реалізація механізмів автентифікації та захисту API .......................................... 51 
3.1.1 Конфігурація Spring Security та рольова політика доступу. ........................ 52 
3.1.2 Реалізація JWT-автентифікації (генерація, валідація, фільтрація).. ........... 55 
3.2 Реалізація підсистеми аудиту подій безпеки ........................................................ 59 
3.2.1 Доменна модель та персистентність записів аудиту.. .................................. 60 
3.2.2 Сервіс аудиту та інтеграція з бізнес-процесами.. ......................................... 61 
3.3 Тестування та верифікація модуля безпеки .......................................................... 63 
3.3.1 Результати функціонального тестування.. .................................................... 64 
3.3.2 Демонстрація роботи модуля. ......................................................................... 65 
Висновки до розділу 3 .................................................................................................. 67 
ВИСНОВКИ ....................................................................................................................... 69 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................................... 71 
ДОДАТОК А. Специфікація 482.ЧДТУ.62289-01 .......................................................... 73 
ДОДАТОК Б. Текст програми ........................................................................................... 75 
ДОДАТОК В. Інструкція користувача .............................................................................. 80 
ДОДАТОК Г. Апробація кваліфікаційної роботи бакалавра. ......................................... 83 
 
 
10 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І 
ТЕРМІНІВ 
API – Application Programming Interface (прикладний програмний інтерфейс); 
BCrypt – адаптивний алгоритм хешування паролів; 
БД – база даних; 
ETL – Extract, Transform, Load (витягнення, перетворення, завантаження); 
HR – Human Resources (управління персоналом); 
HTTP – Hypertext Transfer Protocol (протокол передачі гіпертексту); 
IAM – Identity and Access Management (керування ідентифікацією та доступом); 
JSON – JavaScript Object Notation (формат обміну даними); 
JWT – JSON Web Token; 
ORM – Object-Relational Mapping (об'єктно-реляційне відображення); 
ПЗ – програмне забезпечення; 
RBAC – Role-Based Access Control (рольове керування доступом); 
REST – Representational State Transfer; 
СКБД – система керування базами даних; 
SSO – Single Sign-On (єдиний вхід до системи); 
XLSX – формат електронних таблиць Microsoft Excel. 
  
11 
ВСТУП 
Цифрова трансформація управлінських процесів у закладах освіти та 
державних установах зумовила активний перехід від паперового документообігу до 
інтегрованих інформаційних систем. Для HR-напряму це означає не лише 
автоматизацію кадрових процедур, а й необхідність безпечної обробки значних 
масивів персональних даних. Особливої актуальності ця задача набуває у сфері 
військового обліку, де оброблювана інформація містить чутливі персональні та 
службові відомості: ідентифікаційні реквізити, дані військового статусу, інформацію 
про територіальні центри комплектування, відомості щодо відстрочок і супровідну 
звітну документацію. За таких умов модуль контролю доступу та базової безпеки є не 
додатковою опцією, а критичним компонентом архітектури системи. 
Актуальність теми. Актуальність теми кваліфікаційної роботи бакалавра 
визначається сукупністю організаційних, правових і технічних чинників.  
По-перше, в умовах зростання кіберризиків [1] будь-яка помилка в механізмах 
автентифікації, авторизації чи журналювання дій користувачів може призвести до 
несанкціонованого доступу, витоку даних або порушення цілісності облікової 
інформації.  
По-друге, системи військового обліку мають забезпечувати відтворюваність 
операцій і прозорість дій персоналу, що вимагає впровадження аудиту подій і 
керованого життєвого циклу критичних бізнес-процесів.  
По-третє, практична експлуатація HR-систем вимагає балансу між безпекою 
та зручністю: обмеження доступу не повинні блокувати роботу кадрового підрозділу, 
але мають гарантовано мінімізувати ризики порушення режиму доступу. 
У сучасній практиці інформаційної безпеки сформувалися стійкі підходи до 
побудови таких систем: принцип найменших привілеїв, багаторівнева перевірка 
доступу, stateless-автентифікація для API, централізоване логування, контроль 
цілісності бізнес-операцій, а також безперервний моніторинг подій. З огляду на це, 
реалізація модуля безпеки в HR-системі  військового обліку має спиратися не на 
локальні «точкові» перевірки, а на цілісну архітектурну модель, у якій безпекові 
12 
правила вбудовані в логіку взаємодії клієнта, серверу, бази даних і прикладних 
сервісів. 
Загальна оцінка сучасного стану проблеми свідчить, що на ринку існує багато 
зрілих корпоративних HR-платформ (зокрема SAP SuccessFactors, Oracle HCM, 
Workday, BambooHR), які реалізують рольові моделі доступу та аудит операцій. 
Водночас ці рішення є універсальними й орієнтовані на широкий спектр бізнес-
сценаріїв, тоді як підсистеми військового обліку мають доменно-специфічні вимоги: 
спеціалізований набір реквізитів, формалізований документообіг, регламентовані 
маршрути перевірки й актуалізації, підвищені вимоги до конфіденційності. У 
науково-методичному контексті базові підходи до рольового керування доступом 
закладені в працях R. Sandhu, D. Ferraiolo, R. Kuhn [2]; їх розвиток підтримують 
стандарти і рекомендації NIST [3] та міжнародні практики серії ISO/IEC 27000 [4]. 
Однак безпосередня адаптація цих підходів до прикладної системи військового HR-
обліку потребує окремого інженерного обґрунтування і практичної реалізації. 
Світові тенденції розвитку безпечних інформаційних систем у цій предметній 
області пов’язані з переходом до сервісної архітектури, API-first підходу, подієвих 
механізмів обміну станами, container-based розгортання, систематичного аудиту та 
розширення засобів автоматизованого контролю якості даних. Окремо варто 
відзначити тенденцію до впровадження Role-Based Access Control (RBAC) [2] та 
stateless-автентифікації на базі JWT [5] для захисту кадрової інформації. 
Зв’язок роботи з науковими програмами, планами і темами кафедри 
комп’ютерних наук та системного аналізу (КНСА) визначається її спрямованістю на 
розроблення прикладного програмного забезпечення в галузі комп’ютерних наук, 
автоматизацію процесів захисту даних та підвищення якості контролю доступу в 
корпоративних інформаційних системах. Результати дослідження узгоджуються з 
тематикою науково-дослідних робіт кафедри КНСА, що стосуються проєктування 
інформаційних систем, інтеграції безпекових компонентів і застосування сучасних 
технологій захисту інформації. 
Тема кваліфікаційної роботи бакалавра безпосередньо пов’язана з практичним 
завданням створення інформаційної системи HR-Office для автоматизації військового 
13 
обліку в університетському середовищі. У рамках проєкту реалізується клієнт-
серверна архітектура: серверна частина на Spring Boot, клієнтська частина на Kotlin 
Multiplatform (Compose Desktop), з REST-взаємодією та централізованим зберіганням 
даних у PostgreSQL [6]. Відповідно, модуль контролю доступу та базової безпеки 
формує фундамент довіри до всієї системи: від входу користувача до операцій 
пошуку, фільтрації, оновлення, імпорту та генерації документів. 
Практичний стан реалізації підтверджує, що базовий безпековий контур 
інтегрований у ключові елементи системи. На сервері застосовано Spring Security [7] 
зі stateless-політикою сесій, JWT-фільтрацію запитів і BCrypt-хешування паролів; 
публічними залишено контур авторизації та технічні ендпоінти документації/health-
check, тоді як решта API вимагає автентифікації. Реалізовано endpoint входу 
користувача, формування JWT та перевірку токена в кожному запиті. У поточній 
конфігурації рольова перевірка явно застосовується для окремих службових 
маршрутів (зокрема actuator), а для більшості прикладних операцій діє перевірка рівня 
«автентифікований користувач». 
Окрему цінність має реалізована підсистема аудиту подій (Audit Log), яка 
забезпечує фіксацію критичних операцій у базі даних із прив'язкою до типу дії, 
цільової сутності та часових параметрів. Такий підхід формує доказову базу для 
аналізу інцидентів, контролю відповідності політикам безпеки та підвищення 
простежуваності дій користувачів. З погляду безпеки це важливо тим, що кожна 
значуща операція не залишається непростежуваною, а фіксується в журналі з 
можливістю подальшого аудиту та розслідування. 
Додатково реалізовано аудит операцій, що формує доказову базу для аналізу 
інцидентів і внутрішнього контролю. У системі передбачено збереження записів про 
дії, пов'язані з критичними операціями та історією подій, що відповідає вимогам 
простежуваності дій користувачів у задачах військового обліку. Розвиток цього 
напряму є одним із ключових практичних резервів підвищення зрілості безпекового 
модуля. 
Стан проєкту також демонструє узгоджений розвиток суміжного функціоналу, 
який прямо впливає на безпеку та якість даних: реалізовано пошук, фільтрацію і 
14 
сортування реєстру, імпорт даних із XLSX із валідацією та обробкою помилок, 
інтеграційні тести для критичних сценаріїв, а також оновлення клієнтської частини 
під відповідні API-контракти. Наявність таких змін у поточній історії комітів 
підтверджує практичну спрямованість роботи та знижує ризик «декларативної» 
безпеки, коли захист описаний, але не інтегрований у реальні бізнес-процеси. 
Отже, проблема, що розглядається у кваліфікаційній роботі бакалавра, є 
актуальною і має прикладний характер: необхідно забезпечити надійний контроль 
доступу та базову інформаційну безпеку в HR-системі військового обліку при 
збереженні працездатності щоденних операцій кадрової служби. Її розв’язання 
потребує поєднання архітектурних рішень, інженерних механізмів захисту, 
інструментів аудиту та узгодженості між серверною й клієнтською частинами 
системи. 
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра є 
проєктування та програмна реалізація модуля контролю доступу і базової безпеки в 
HR-системі  військового обліку, який забезпечує захищений доступ до функціоналу 
системи, контроль виконання критичних операцій та простежуваність дій 
користувачів. 
Для досягнення поставленої мети сформульовано такі завдання: 
– провести аналіз предметної області HR-системи військового обліку та 
визначити ключові ризики інформаційної безпеки; 
– проаналізувати сучасні підходи до автентифікації, авторизації, рольового 
розмежування доступу й аудиту подій; 
– обґрунтувати архітектурні принципи побудови модуля контролю доступу в 
клієнт-серверній системі; 
– реалізувати механізми безпечного входу, перевірки токенів та захисту API – 
запитів; 
– реалізувати модуль безпеки API та систему аудиту подій (Audit Log) із 
коректною обробкою помилок безпеки; 
– реалізувати базовий аудит дій користувачів і подій безпеки; 
– забезпечити узгодження безпекового контуру серверної і клієнтської частин; 
15 
– виконати перевірку працездатності реалізованих рішень на тестових 
сценаріях. 
Об’єкт дослідження: процеси організації доступу до даних і функціональних 
можливостей HR-системи військового обліку. 
Предмет дослідження: методи, моделі та програмні засоби реалізації 
контролю доступу і базової безпеки в клієнт-серверній HR-системі військового 
обліку. 
Методи дослідження: системний аналіз предметної області, аналіз сучасних 
підходів і стандартів інформаційної безпеки, моделювання ролей і політик доступу, 
методи проєктування програмних систем, а також методи прикладної реалізації та 
тестування програмного забезпечення. 
Апробація результатів роботи. Основні положення і результати 
кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції 
«День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна. 
Командний проєкт (Благовісний Юрій Олександрович, Голуб Данило 
Русланович, Дубровний Володимир Володимирович, Кєрнус Дмитро Олександрович) 
«Інформаційна автоматизована HR-система закладу вищої освіти» в День 
студентської науки кафедри КНСА посів 1 місце. 
Публікації. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л. 
П. Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована HR-
система закладу вищої освіти  : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.]; 
Міністерство освіти і науки України, Черкаський державний технологічний ун-т.  
Черкаси : ЧДТУ, 2026. С. 14. 
Практичне значення отриманих результатів полягає в підвищенні 
захищеності доступу до персональних та службових даних, забезпеченні керованого 
розмежування повноважень користувачів, підвищенні прозорості та відтворюваності 
дій у системі за рахунок аудиту подій, а також у формуванні основи для подальшого 
розвитку безпекових механізмів HR-системи військового обліку. 
Таким чином, тема «Модуль контролю доступу та базової безпеки в HR-системі 
16 
військового обліку» є своєчасною, науково-обґрунтованою та практично значущою. 
Її реалізація спрямована на вирішення конкретної прикладної проблеми: створення 
керованого й надійного безпекового контуру, який забезпечує конфіденційність, 
цілісність і контрольованість обробки даних у критично важливих HR-процесах 
військового обліку. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
17 
1 ТЕОРЕТИКО-АНАЛІТИЧНІ ЗАСАДИ КОНТРОЛЮ ДОСТУПУ ТА 
БАЗОВОЇ БЕЗПЕКИ В HR-СИСТЕМІ  ВІЙСЬКОВОГО ОБЛІКУ 
1.1 Предметна область HR-систем и військового обліку та постановка 
проблеми безпеки 
Предметна область дослідження охоплює процеси ведення військового обліку 
в межах HR-системи, що забезпечує накопичення, оновлення та використання 
персональних і військово-облікових даних. На відміну від звичайного кадрового 
обліку, ця сфера характеризується підвищеною чутливістю інформації, 
регламентованістю документообігу та високими вимогами до точності обробки даних 
[1]. Саме тому питання доступу до відомостей і функцій системи має не допоміжний, 
а критично важливий характер. 
Проблема безпеки в даній предметній області полягає в необхідності одночасно 
забезпечити конфіденційність, цілісність і контрольованість обробки даних за умов 
багаторольової роботи користувачів. Практичні ризики пов’язані з несанкціонованим 
доступом, надмірними повноваженнями, некоректними змінами записів, а також 
недостатньою простежуваністю критичних операцій. Отже, постановка проблеми 
зводиться до створення керованого безпекового контуру, в якому перевірка особи, 
розмежування прав та аудит подій діють узгоджено. 
Подальший виклад у підрозділі спрямовано на деталізацію особливостей 
процесів військового обліку, визначення складу критичних даних, аналіз ключових 
загроз та формування вимог до захисту доступу як бази для проєктних рішень. 
Для вирішення вказаних завдань у межах колективного проєкту було 
спроєктовано комплексну структуру, що об'єднує розробки чотирьох авторів у єдину 
екосистему. Розроблена HR-система військового обліку державного закладу освіти 
інтегрує чотири функціональні модулі в єдину захищену екосистему. 
Взаємозв'язок функціональних модулів загальної HR-системи військового 
обліку ЗВО наведено на рисунку 1.1. 
 
18 
 
Рисунок 1.1 – Контекстна схема предметної області HR-системи військового обліку 
 
Призначення модулів: 
Модуль контролю доступу та безпеки (Модуль 4) виступає як захисний бар'єр 
системи, забезпечуючи автентифікацію користувачів, розмежування ролей 
(адміністратор, інспектор відділу кадрів) та ведення журналів аудиту дій. 
Модуль інтеграції та міграції даних (Модуль 1) відповідає за первинне 
наповнення бази даних, дозволяючи імпортувати інформацію про студентів та 
співробітників із зовнішніх інформаційних систем університету або XLSX/CSV 
файлів. 
Модуль обліку військовозобов'язаних (Модуль 2) є ядром системи, яке зберігає 
структуровані картки обліку військовозобов'язаних осіб, їхні персональні та 
військово-облікові дані. 
19 
Модуль формування довідок та звітів (Модуль 3) використовує дані з ядра 
системи для автоматичного генерування регламентованих документів (наприклад, 
довідок для надання в ТЦК за встановленою формою або зведених звітів). 
1.1.1 Особливості процесів військового обліку в HR-системі та склад 
критичних даних. Військовий облік у межах HR-системи є комплексом 
взаємопов’язаних процесів, спрямованих на збирання, актуалізацію, зберігання та 
використання персональних і службових відомостей про призовників, 
військовозобов’язаних і резервістів. На відміну від загального кадрового обліку, дана 
предметна область характеризується підвищеною чутливістю даних, 
регламентованістю документообігу та високими вимогами до точності обробки 
інформації. Помилки в реквізитах, затримки актуалізації або порушення режиму 
доступу безпосередньо впливають на достовірність обліку та якість управлінських 
рішень [6]. 
Узагальнену контекстну схему предметної області та основних інформаційних 
потоків наведено на рисунку 1.1. 
 
Рисунок 1.1 – Контекстна схема предметної області HR-системи військового 
обліку 
Ключовою особливістю таких процесів є поєднання стандартних HR-операцій 
20 
із військово-обліковими сценаріями. До базових операцій належать ведення реєстру 
осіб, пошук і фільтрація записів, перегляд розширених карток, оновлення анкетних та 
облікових реквізитів. До спеціалізованих операцій належать формування 
регламентованих документів, фіксація історії змін, контроль статусів обліку, робота з 
відомостями про відстрочки, військово-облікову спеціальність, реквізити військових 
документів, а також зберігання відомостей про відповідні органи військового обліку. 
Процеси в системі мають циклічний характер: первинне внесення даних, 
перевірка повноти, подальше уточнення, документальне оформлення змін і аудит 
виконаних дій. Така циклічність підвищує вимоги до узгодженості даних між 
підсистемами. Якщо в звичайних інформаційних системах допустимі локальні 
неточності, то для військового обліку навіть часткова неактуальність реквізитів 
створює ризик управлінських помилок і порушення внутрішніх регламентів. 
Для даної предметної області критично важливими є декілька груп даних. 
Перша група-ідентифікаційні персональні відомості: прізвище, ім’я, по батькові, дата 
народження, податковий номер, паспортні реквізити, адресні дані. Друга група -
військово-облікові відомості: категорія обліку, військове звання, військово-облікова 
спеціальність, дані про перебування на обліку, відомості щодо відстрочок і 
пов’язаних обмежень. Третя група-службово-процесні дані: ознаки актуалізації, 
історія змін, результати валідації, статуси сформованих документів, службові події 
користувачів. 
Окремо слід виділити службово-процесні дані, що формуються системою в 
процесі роботи. Йдеться про записи аудиту, журнали подій безпеки та результати 
перевірок доступу. Для таких операцій важливо не лише зафіксувати факт дії, а й 
забезпечити прив'язку до суб'єкта доступу, типу операції та часових параметрів. Саме 
тому в сучасних реалізаціях аудит подій розглядається як обов'язковий компонент 
безпекового контуру із збереженням записів у персистентному сховищі. 
Суттєвою ознакою предметної області є багаторольова взаємодія користувачів 
із системою. У реальних умовах експлуатації різні категорії користувачів мають різні 
функціональні повноваження: перегляд, редагування, ініціація формування 
документів, контроль історії подій. Це формує пряму вимогу до розмежування 
21 
доступу за ролями та сценаріями дій, а також до виключення надмірних прав. Без 
чіткої моделі доступу система або втрачає керованість, або стає надмірно 
обмежувальною для операційної роботи. 
Ще однією важливою особливістю є залежність якості військового обліку від 
якості вхідних даних. У практичних сценаріях інформація може надходити з різних 
джерел, зокрема у вигляді пакетного імпорту. Це потребує попередньої нормалізації, 
перевірки формату, виявлення дублікатів та фіксації помилок обробки. Відповідно, 
безпека в даному контексті включає не лише “захист від зловмисника”, а й захист від 
процесних ризиків: неконсистентності, втрати цілісності та несанкціонованої 
модифікації даних. 
Для предметної області військового обліку також характерна підвищена роль 
аудиту. Оскільки система використовується для обробки чутливої інформації та 
формування офіційних документів, кожна критична дія має бути простежуваною: хто 
виконав операцію, коли, над яким записом і з яким результатом. Наявність журналу 
подій перетворює безпековий контур із декларативного на керований, забезпечує 
основу для внутрішнього контролю і спрощує аналіз інцидентів. 
Таким чином, процеси військового обліку в HR-системі  мають високу ступінь 
регламентованості, чутливість до якості даних та значну залежність від коректного 
розмежування доступу. Склад критичних даних охоплює персональні, військово-
облікові та службово-процесні відомості, що в сукупності обґрунтовує необхідність 
впровадження модуля контролю доступу та базової безпеки як обов’язкової складової 
архітектури системи. 
1.1.2 Ключові загрози інформаційній безпеці та вимоги до захисту доступу. 
Інформаційна безпека HR-системи військового обліку визначається не лише 
технічними засобами захисту, а й якістю організації доступу до даних та функцій 
системи.  
Для такої предметної області ризики мають комплексний характер [4]: вони 
поєднують зовнішні кіберзагрози, внутрішні порушення регламенту, помилки 
користувачів та процесні збої під час обробки облікової інформації. Саме тому аналіз 
загроз має розглядатися як обов’язкова передумова формування вимог до модулю 
22 
контролю доступу.  
Класифікацію ключових загроз та їх зв’язок із вимогами до захисту доступу 
наведено на рисунку 1.2. 
До першої групи загроз належать загрози несанкціонованого доступу. Їх 
джерелом може бути використання компрометованих облікових даних, спроби 
обходу перевірок автентифікації, доступ до захищених API без належного маркера 
авторизації, а також використання надмірних прав у межах валідної сесії користувача. 
Для системи військового обліку ці загрози є критичними, оскільки відкривають 
доступ до персональних і військово-облікових відомостей, що належать до чутливих 
категорій даних. 
 
Рисунок 1.2 – Класифікація загроз інформаційній безпеці в HR-системі 
військового обліку 
Друга група загроз пов’язана з порушенням цілісності даних. Мова йде про 
несанкціоноване редагування реквізитів, внесення помилкових або неповних значень, 
неконсистентні зміни під час масових операцій імпорту, а також втрату узгодженості 
між взаємопов’язаними атрибутами запису. У контексті військового обліку наслідком 
може бути формування некоректних документів, неправильна інтерпретація статусу 
обліку особи та помилки управлінського характеру. 
Третя група загроз стосується конфіденційності. Навіть за умови відсутності 
23 
прямого втручання в БД витік можливий через надмірно широкі права перегляду, 
передачу даних незахищеними каналами, неконтрольоване копіювання документів 
або відсутність аудиту дій користувачів. Для системи військового обліку порушення 
конфіденційності створює правові та репутаційні ризики, а також ускладнює 
подальше функціонування системи в організаційному середовищі. 
Четверта група загроз охоплює доступність і керованість сервісу. Критичними 
є відмови в процесах генерації документів, збої в ланцюжку обробки задач, 
некоректна обробка помилок у запитах, а також відсутність прозорого механізму 
контролю стану операції. Якщо система не забезпечує передбачуваний цикл 
виконання критичних дій, це призводить до втрати довіри користувачів і до 
накопичення операційних помилок. 
П’ята група загроз пов’язана з відсутністю або недостатністю простежуваності 
подій. Якщо система не фіксує, хто саме ініціював формування документа, зміну 
запису або іншу критичну операцію, виникає неможливість ефективного аудиту та 
розслідування інцидентів. Для предметної області військового обліку така ситуація є 
неприйнятною, оскільки контрольованість дій користувачів є частиною базової 
безпеки. 
З урахуванням наведених загроз формуються ключові вимоги до захисту 
доступу в HR-системі  військового обліку. 
По-перше, система має забезпечувати надійну автентифікацію користувача 
перед наданням доступу до будь-яких захищених ресурсів. Це означає централізовану 
перевірку облікових даних, використання безпечного зберігання паролів і 
унеможливлення доступу до API без валідного маркера автентифікації. 
По-друге, необхідне чітке розмежування повноважень на рівні ролей і операцій. 
Користувач повинен мати доступ лише до тих дій, що відповідають його службовим 
функціям. Принцип мінімально необхідних прав має застосовуватися як для 
перегляду даних, так і для операцій редагування, імпорту, формування документів та 
доступу до адміністративних ендпоінтів. 
По-третє, система повинна підтримувати захист прикладного API як основної 
точки взаємодії клієнта і сервера. Кожен запит до захищених маршрутів має 
24 
проходити перевірку контексту авторизації, а публічні маршрути мають бути 
обмежені лише технічно необхідним мінімумом. 
По-четверте, обов’язковою є наявність механізмів аудиту подій безпеки. Для 
критичних дій система має зберігати факт операції, її тип, цільову сутність і часові 
параметри. Такий підхід забезпечує простежуваність, підвищує керованість і створює 
основу для післяінцидентного аналізу. 
По-п’яте, операції з підвищеною важливістю (зокрема генерація документів) 
повинні виконуватися в керованому процесі з контрольованими станами, валідацією 
вхідних даних і явною обробкою помилок. Це знижує ризик прихованих збоїв і 
забезпечує передбачуваність результату для користувача. 
По-шосте, система повинна враховувати нефункціональні вимоги до безпеки: 
захист каналів передавання даних, контроль терміну дії токенів доступу, стійкість до 
помилкових запитів, а також сумісність безпекових механізмів із загальною 
архітектурою та продуктивністю системи. 
Таким чином, аналіз загроз у предметній області військового обліку 
підтверджує, що безпека HR-системи має будуватися як багаторівнева модель: 
автентифікація, авторизація, захист API, контрольований цикл критичних операцій і 
аудит дій користувачів. Сукупність цих вимог формує концептуальну основу для 
подальшого проєктування та реалізації модуля контролю доступу і базової безпеки. 
1.2 Аналіз сучасних підходів і рішень для забезпечення контролю доступу 
Сучасні підходи до контролю доступу в інформаційних системах базуються на 
поєднанні механізмів автентифікації, авторизації та політик допуску до операцій. Для 
систем, що працюють із чутливими даними, критично важливо не лише підтвердити 
особу користувача, а й забезпечити контекстно коректне надання прав на кожну дію. 
У зв’язку з цим аналіз технологічних рішень має проводитися за критеріями безпеки, 
масштабованості, керованості та сумісності з архітектурою застосунку. 
Для HR-системи військового обліку найбільш релевантними є рольові моделі 
доступу, токен-орієнтована автентифікація та багаторівневі політики авторизації на 
рівні API і прикладної логіки. Порівняння альтернативних підходів дозволяє 
25 
визначити їхні переваги та обмеження в умовах реальної експлуатації: від керування 
правами користувачів до забезпечення стабільного доступу до критичних процесів 
імпорту і генерації документів. 
У межах підрозділу виконано аналіз базових моделей автентифікації та 
авторизації, а також порівняльне обґрунтування вибору підходу. 
1.2.1 Моделі автентифікації та авторизації в інформаційних системах 
(RBAC, JWT, рольові політики). У сучасних інформаційних системах контроль 
доступу ґрунтується на поєднанні двох базових механізмів: автентифікації та 
авторизації. Автентифікація відповідає на питання «хто саме виконує запит», а 
авторизація визначає «які дії цьому суб’єкту дозволені».  
Для систем із чутливими даними, зокрема для HR-системи військового обліку, 
ці механізми не можуть реалізовуватися ізольовано: лише їх спільна робота 
забезпечує керований і безпечний доступ до функціоналу. 
Автентифікація в прикладних системах зазвичай реалізується через перевірку 
облікових даних користувача (логін/пароль) із подальшим формуванням контексту 
безпеки. Ключовими вимогами до цього етапу є: захищене зберігання паролів у 
вигляді криптостійких хешів, контроль правильності облікових даних, обмеження 
доступу до ресурсів до моменту успішної перевірки особи. У практичних веб-і API-
орієнтованих рішеннях все частіше використовується модель stateless-автентифікації, 
коли сервер не підтримує тривалі сесії стану, а довіра до запиту формується на основі 
валідного маркера доступу. 
Одним із найпоширеніших інструментів stateless-підходу є JWT (JSON Web 
Token) [5]. У такій моделі після успішного входу користувача сервер генерує 
підписаний токен із обмеженим терміном дії. Надалі клієнт додає токен до запитів, а 
сервер верифікує його цілісність, строк чинності та суб’єкт доступу. Перевагами 
підходу є зручність масштабування, спрощення інтеграції між клієнтом і REST API, 
а також відсутність потреби зберігати сесійну інформацію на сервері. Для домену 
військового обліку це важливо, оскільки дає змогу побудувати передбачуваний 
захищений контур доступу для клієнт-серверної взаємодії. 
Разом із тим JWT-підхід вимагає дотримання низки умов безпечної реалізації: 
26 
використання надійного алгоритму підпису, контроль часу життя токена, захист 
каналу передавання даних, коректна обробка помилок валідації, а також 
унеможливлення доступу до захищених маршрутів без маркера. Якщо ці умови 
порушуються, токенна модель втрачає свою безпекову ефективність. 
Після етапу автентифікації ключовим стає етап авторизації. Найбільш 
практичною моделлю для прикладних HR-системє RBAC (Role-Based Access Control) 
[2] керування доступом на основі ролей. Її суть полягає в тому, що права 
призначаються не окремим користувачам безпосередньо, а ролям; користувач 
отримує права через належність до ролі. Такий підхід спрощує адміністрування 
доступу, знижує ризик накопичення випадкових прав і забезпечує кращу прозорість 
політик безпеки. 
У моделі RBAC роль формалізує функціональні обов’язки користувача в 
системі. Наприклад, одні ролі можуть мати повний доступ до операцій редагування 
та генерації документів, інші обмежений доступ лише до перегляду. Для військово-
облікового контуру це особливо доречно, оскільки дозволяє прив’язати доступ до 
службової відповідальності та мінімізувати ризик надмірних повноважень. 
До переваг RBAC належать: централізованість керування, простота аудиту 
призначених прав, масштабованість при зростанні кількості користувачів, 
узгодженість із організаційною структурою підрозділів. Обмеженням класичної 
RBAC-моделі є те, що вона не завжди враховує контекст операції (час, стан об’єкта, 
додаткові атрибути середовища). Тому, в практичних системах її часто доповнюють 
політиками прикладного рівня та перевірками бізнес-умов. 
Рольові політики доступу є логічним розширенням RBAC у прикладній 
архітектурі. Вони визначають правила допуску до конкретних API-операцій, дій 
інтерфейсу та критичних бізнес-процесів. На відміну від абстрактного «має роль», 
політика формалізує «за яких умов роль може виконати саме цю дію». Для HR-
системи військового обліку це означає розділення доступу не лише за категорією 
користувача, а й за типом операції: перегляд реєстру, редагування картки, імпорт 
даних, формування документа, доступ до службових ендпоінтів та інструментів 
моніторингу. 
27 
Сучасна практика побудови безпечних систем передбачає багаторівневу 
авторизацію: на рівні HTTP-маршруту, на рівні сервісної логіки та на рівні доменних 
обмежень. Така композиція критично важлива для систем із чутливими даними, 
оскільки знижує ймовірність обходу перевірок через неочевидні сценарії 
використання API. Якщо перевірка існує лише в одному шарі, ризик помилок 
проєктування суттєво зростає. 
У зв’язці RBAC+JWT роль користувача зазвичай потрапляє в контекст безпеки 
після валідації токена, а далі використовується для прийняття рішення щодо допуску 
до ресурсу. За наявності коректної конфігурації це дає послідовну й технологічно 
просту модель доступу, сумісну з REST-архітектурою та клієнтськими застосунками 
різних типів. Для проєкту HR-системи військового обліку така модель є доцільною, 
оскільки поєднує безпекову достатність, керованість і можливість подальшого 
розширення політик. 
Окремої уваги потребує зв’язок авторизації з аудитом. У зрілих системах 
рішення «дозволити/заборонити» має бути не лише виконаним, а й простежуваним у 
контексті події. Логування критичних операцій із прив’язкою до суб’єкта доступу 
підвищує контрольованість і забезпечує практичну перевірюваність політик безпеки. 
Для предметної області військового обліку це є обов’язковою умовою 
експлуатаційної надійності. 
Тому, аналіз моделей автентифікації та авторизації показує, що для HR-системи 
військового обліку найбільш обґрунтованим є поєднання stateless-автентифікації на 
основі JWT із рольовою моделлю RBAC та чітко визначеними політиками доступу до 
операцій. Такий підхід забезпечує необхідний рівень захисту, підтримує 
масштабованість системи та створює основу для подальшого розвитку безпекового 
контуру. 
1.2.2 Порівняльний аналіз існуючих підходів і обґрунтування вибору для 
HR-системи військового обліку. Під час проєктування контуру безпеки для HR-
системи військового обліку доцільно порівняти кілька базових підходів до керування 
доступом:  
– класичну сесійну модель (server-side session); 
28 
– токен-орієнтовану модель з JWT; 
– модель з непрозорими (opaque) токенами через окреме сховище; 
– більш важкі інфраструктурні варіанти на кшталт повного SSO-контуру [1].  
Вибір не може базуватися лише на популярності технології, тому ключовими 
критеріями є: рівень контролю доступу за ролями, масштабованість, стійкість до 
типових атак, простота супроводу, сумісність із REST-взаємодією та зручність 
інтеграції з десктопним клієнтом. Порівняння підходів до контролю доступу для HR-
системи військового обліку наведено в таблиці 1.1. 
Таблиця 1.1 – Порівняння підходів до контролю доступу для HR-системи військового 
обліку 
Підхід Рівень Масштабова Складність Сумісність Придатність 
 безпеки ність супроводу з REST/API для проєкту 
Server-side Середній Середня/низь Середня Обмежена Обмежено 
session ка при для доцільний 
горизонталь- stateless-
ному взаємодії 
масштабува-
нні 
Opaque Високий за Середня Висока Добра, але з Частково 
token+ умови додатковою доцільний 
сховище надійної латентністю 
інфрастру-
ктури 
токенів 
JWT Високий за Висока Низька/ Висока Доцільний 
(stateless) коректної середня 
реалізації 
JWT+ Високий Висока Середня Висока Оптимальний 
RBAC вибір 
Повноцінн Високий Висока Висока Висока Надмірний 
ий SSO- для поточного 
контур масштабу 
(OIDC/IdP) 
Гібридна Дуже Висока Вище Висока Перспектив-
модель високий середньої ний етап 
(JWT+ розвитку 
контекстні 
політики) 
29 
Сесійний підхід історично є простим у впровадженні, але передбачає зберігання 
серверного стану (session store), що ускладнює горизонтальне масштабування і 
підвищує операційні витрати. Для системи, де передбачені ролі користувачів та 
багато захищених API-операцій над даними студентів і документів, централізоване 
зберігання сесій створює додаткову точку відмови і потребує синхронізації між 
інстансами застосунку. 
Підхід із непрозорими токенами частково вирішує питання керування 
життєвим циклом доступу, але також вимагає постійної перевірки токена у 
серверному сховищі. Це означає додаткові звернення до БД/кешу майже для кожного 
запиту, що збільшує затримки та ускладнює експлуатацію. Для розробленої системи, 
де важливі передбачувана продуктивність і простий шлях супроводу, такий варіант є 
менш раціональним. 
Токен-орієнтована безстанова модель на базі JWT у поєднанні з рольовою 
політикою доступу відповідає функціональній моделі проєкту. Після автентифікації 
користувач отримує підписаний токен із мінімально необхідними даними і строком 
дії, а подальший доступ до REST-ресурсів перевіряється на рівні фільтра безпеки та 
серверного контексту авторизації. Сервер не зберігає стан сесії, що спрощує 
масштабування і робить поведінку системи стабільнішою під навантаженням. 
Для порівнюваної предметної області важливо, що модель JWT+RBAC 
природно відображає рольову структуру («користувач»/«адміністратор») і дозволяє 
точно обмежити доступ до критичних операцій. У практичній реалізації це 
підкріплюється криптографічним хешуванням паролів (BCrypt) і фільтрацією 
неавторизованих запитів до захищених endpoint’ів, тобто поєднується контроль 
ідентичності та контроль повноважень. 
Окремо слід відзначити придатність такого підходу для архітектури 
«десктопний клієнт+REST API». На відміну від складніших SSO-сценаріїв, обрана 
модель не вимагає розгортання додаткового контуру ідентифікації, але забезпечує 
достатній рівень базової безпеки для задач кадрового обліку, включно з доступом до 
операцій генерації документів, імпорту даних та перегляду реєстрів. 
Отже, за сукупністю критеріїв (масштабованість, керованість, вартість 
30 
супроводу, відповідність ролям системи та практична інтегрованість із наявною 
архітектурою) найбільш обґрунтованим для даної HR-системи є вибір безстанової 
моделі автентифікації з JWT у поєднанні з рольовою авторизацією RBAC і BCrypt для 
зберігання облікових даних. Саме цей вибір забезпечує необхідний баланс між 
захищеністю, продуктивністю та простотою подальшого розвитку програмного 
комплексу. 
1.3 Обґрунтування напрямів реалізації модуля контролю доступу та 
базової безпеки в проєкті 
На підставі проведеного теоретико-аналітичного дослідження визначено 
напрями практичної реалізації модуля контролю доступу в архітектурі проєкту. 
Ключовим завданням є трансформація загальних принципів безпеки у конкретні 
функціональні механізми, які можна стабільно застосувати в серверній і клієнтській 
частинах системи без порушення бізнес-процесів. 
Обґрунтування напрямів реалізації включає формування вимог до 
автентифікації, рольової авторизації, захисту API, керованого виконання критичних 
операцій та аудиту подій безпеки. Водночас враховуються нефункціональні критерії: 
продуктивність, масштабованість, надійність, супроводжуваність і тестованість. 
Такий підхід забезпечує не фрагментарний, а системний характер безпекового 
контуру. 
Подальші пункти підрозділу конкретизують ці напрями через опис 
функціональних і нефункціональних вимог та логіку інтеграції безпекових механізмів 
у загальну архітектуру проєкту. 
1.3.1 Функціональні та нефункціональні вимоги до модуля контролю 
оступу. Модуль контролю доступу в HR-системі військового обліку має 
забезпечувати керований і безпечний доступ до даних студентів, операцій імпорту та 
формування документів. Вимоги до модуля формуються з урахуванням ролей 
користувачів, API-архітектури застосунку та необхідності захисту персональних 
даних. 
Розглянемо детально ці вимоги. 
31 
Функціональні вимоги: 
– Модуль повинен виконувати автентифікацію користувача за парою 
логін/пароль через окрему точку входу. 
– Після успішної автентифікації модуль повинен видавати токен доступу для 
подальших звернень до захищених ресурсів. 
– Модуль повинен здійснювати перевірку токена в кожному запиті до 
захищених endpoint’ів. 
– Модуль повинен забезпечувати авторизацію відповідно до поточної 
серверної конфігурації безпеки, з можливістю подальшого розширення до повної 
ролеорієнтованої моделі (RBAC). 
– Модуль повинен обмежувати виконання критичних операцій 
(адміністрування, імпорт даних, керування довідниками) лише для ролей із 
відповідними правами. 
– Модуль повинен блокувати неавторизований доступ за принципом deny-by 
– default: доступ надається лише явно дозволеним ролям. 
– Модуль повинен забезпечувати коректну обробку помилок безпеки з 
поверненням стандартизованих відповідей про відмову в доступі або невдалу 
автентифікацію. 
– Модуль повинен підтримувати інтеграцію з журналюванням подій, 
насамперед для критичних операцій системи, з розширенням переліку безпекових 
подій у наступних ітераціях. 
– Модуль повинен працювати узгоджено з іншими підсистемами, не 
порушуючи бізнес-процеси перегляду, редагування, імпорту та генерації документів. 
Нефункціональні вимоги: 
– Безпека: паролі мають зберігатися лише у хешованому вигляді із сучасним 
адаптивним алгоритмом; токени мають бути криптографічно підписані; чутливі 
endpoint’и мають бути недоступні без валідного токена. 
– Конфіденційність: передача облікових даних і токенів повинна 
здійснюватися захищеним каналом; система не повинна розкривати внутрішні деталі 
механізмів безпеки у повідомленнях помилок. 
32 
– Продуктивність: перевірка доступу не повинна створювати суттєвих 
затримок для типових операцій користувача в реєстрі студентів і під час викликів API. 
– Масштабованість: механізм автентифікації та авторизації повинен 
залишатися працездатним при зростанні кількості користувачів і паралельних 
запитів, без жорсткої прив’язки до серверної сесії. 
– Надійність: відмова в одному запиті не повинна призводити до порушення 
роботи інших запитів; модуль має забезпечувати передбачувану поведінку у разі 
прострочених або некоректних токенів. 
– Супроводжуваність: правила доступу повинні бути централізованими, 
зрозумілими для розширення та перевірки під час розвитку системи. 
– Тестованість: модуль має допускати автоматичну перевірку сценаріїв 
успішної та неуспішної автентифікації, а також перевірку політик доступу в межах 
наявної конфігурації безпеки; повноцінні рольові security-тести визначено як напрям 
подальшого розширення тестового покриття. 
– Сумісність із клієнтом: механізм доступу повинен коректно працювати з 
десктопним клієнтом, зберігаючи єдиний контракт взаємодії з REST API. 
Тому, сукупність функціональних і нефункціональних вимог визначає модуль 
контролю доступу як базовий елемент захисного контуру системи: він одночасно 
гарантує коректність бізнес-операцій за ролями та створює необхідний рівень базової 
інформаційної безпеки для роботи з персональними даними. 
1.3.2 Логіка реалізації безпекового контуру в архітектурі проєкту. 
Безпековий контур у досліджуваній HR-системі  побудований як наскрізний 
архітектурний механізм, що охоплює всі ключові рівні застосунку: точку входу, 
обробку запиту, перевірку повноважень, виконання бізнес-операцій і фіксацію подій. 
Такий підхід забезпечує не локальний, а системний захист даних військового обліку, 
де кожна операція проходить послідовність контрольних перевірок. 
Узагальнену схему взаємодії компонентів безпекового контуру наведено на 
рисунку 1.3. 
33 
 
Рисунок 1.3 – Логіка реалізації безпекового контуру в архітектурі проєкту 
На вході до системи реалізується автентифікація користувача за обліковими 
даними. Після успішної перевірки формується токен доступу з ідентифікаційними 
атрибутами (subject, часові параметри), після чого запити до API розглядаються як 
потенційно недовірені, доки токен не буде перевірено. Це дозволяє відокремити етап 
встановлення особи від етапу перевірки прав на конкретну дію. 
На рівні транспортної взаємодії безпековий контур працює за безстановою 
моделлю: кожен запит містить власний контекст доступу. Перед передачею запиту до 
прикладної логіки виконується валідація токена, перевірка його актуальності та 
коректності підпису. У разі невідповідності запит відхиляється на ранній стадії, що 
зменшує ризик обходу правил доступу та скорочує навантаження на бізнес-рівень. 
Далі виконується авторизаційна перевірка відповідно до поточної конфігурації 
безпеки. У наявній реалізації для більшості прикладних операцій застосовується 
правило доступу для автентифікованих користувачів, тоді як окремі службові 
маршрути мають явні рольові обмеження. Така конфігурація забезпечує базовий 
контроль доступу та може бути розширена до детальнішої матриці ролей у подальших 
ітераціях. 
Важливою особливістю є інтеграція безпеки з підсистемою аудиту подій. 
Кожна критична операція не лише перевіряється за ролями, а й фіксується в журналі 
аудиту з прив'язкою до суб'єкта доступу, типу дії та цільової сутності. Таким чином, 
система контролює не тільки «хто виконує дію», а й забезпечує простежуваність усіх 
34 
безпеково значущих операцій, що суттєво підвищує керованість і знижує ризик 
непомічених порушень. 
Окремий рівень становить аудит подій безпеки. У поточній реалізації 
фіксуються критичні операції із збереженням записів у базі даних, що забезпечує 
базову простежуваність дій користувачів. Розширення аудиту до ширшого переліку 
безпекових подій (спроби входу, відмови доступу, звернення до критичних 
endpoint'ів) визначено як напрям подальшого розвитку. 
На клієнтському боці логіка безпекового контуру підтримується через 
керування сесією користувача та коректну передачу токена в запитах до API. У 
результаті досягається узгодженість між десктопним інтерфейсом і серверною 
політикою доступу: користувач працює в межах наданих прав, а сервер залишається 
єдиним джерелом істини щодо дозволів. 
Висновки до розділу 1 
У межах розділу узагальнено теоретичні підходи до побудови контролю 
доступу та базової безпеки в інформаційних системах кадрового обліку, а також 
виконано їх адаптацію до специфіки військового обліку. Проведений аналіз 
підтвердив, що для даної предметної області безпека має розглядатися як наскрізна 
властивість архітектури, а не як ізольований технічний модуль. 
За результатами огляду визначено, що найбільш придатною для проєкту є 
безстанова модель автентифікації з токенами доступу в поєднанні з рольовою 
авторизацією. Такий підхід забезпечує збалансоване поєднання захищеності, 
масштабованості та керованості доступом до операцій над персональними даними, 
імпортом і формуванням документів. Обґрунтовано, що застосування рольової 
політики, принципу мінімальних привілеїв і централізованих правил доступу 
дозволяє зменшити ризики несанкціонованих дій та помилок конфігурації. 
Сформульовано функціональні та нефункціональні вимоги до модуля 
контролю доступу: автентифікація користувачів, перевірка прав на кожному етапі 
взаємодії, аудит подій, надійність, тестованість, продуктивність і сумісність із 
клієнтською частиною. Встановлено, що ефективний безпековий контур повинен 
35 
поєднувати перевірку ідентичності, контроль повноважень, процесні обмеження та 
журналювання дій у єдину логічну систему. 
Отже, теоретико-аналітична база, сформована в розділі 1, створює методичне і 
практичне підґрунтя для подальшого проєктування та реалізації модуля контролю 
доступу в HR-системі військового обліку. Отримані висновки є достатніми для 
переходу до наступного розділу, присвяченого проєктним рішенням і реалізації 
безпекового контуру в програмному комплексі.  
36 
2 ПРОЄКТУВАННЯ МОДУЛЯ КОНТРОЛЮ ДОСТУПУ ТА БАЗОВОЇ 
БЕЗПЕКИ В HR-СИСТЕМІ  ВІЙСЬКОВОГО ОБЛІКУ 
2.1 Постановка задачі проєктування безпекового контуру 
Постановка задачі проєктування безпекового контуру для HR-системи 
військового обліку ґрунтується на необхідності забезпечити керований доступ до 
чутливих персональних і службових даних без погіршення працездатності основних 
бізнес-процесів. На практиці це означає, що механізми захисту мають бути 
інтегровані в архітектуру системи як обов’язковий елемент, а не як додатковий 
надбудований функціонал. Відповідно, в межах проєктування розглядається цілісний 
ланцюг: автентифікація користувача, перевірка повноважень, захист API-операцій, 
контроль критичних операцій та фіксація подій для аудиту. 
Узагальнену структуру постановки задачі проєктування безпекового контуру 
подано на рисунку 2.1. 
 
Рисунок 2.1 – Структура постановки задачі проєктування безпекового контуру 
З урахуванням специфіки предметної області задача проєктування 
формулюється як побудова такого безпекового контуру, який одночасно забезпечує: 
недопущення несанкціонованого доступу, збереження цілісності облікової 
37 
інформації, простежуваність критичних дій та передбачуваність обробки операцій 
підвищеної важливості. Ключовим є поєднання рольового розмежування доступу з 
архітектурними обмеженнями прикладного рівня, зокрема для сценаріїв генерації 
документів, імпорту даних і змін у реєстрі. Такий підхід дозволяє мінімізувати ризики 
як зовнішніх загроз, так і внутрішніх процесних помилок. 
Під час постановки задачі також враховується клієнт-серверний характер 
системи, у якому безпекові рішення мають бути узгоджені між серверною частиною 
та десктопним клієнтом. Це вимагає єдиного контракту взаємодії для захищених 
запитів, коректного керування токеном доступу, стандартизованої обробки відмов та 
підтримки механізмів контролю стану операцій. У результаті проєктування 
безпекового контуру розглядається як інженерна задача системного рівня, 
спрямована на досягнення балансу між захищеністю, керованістю та 
експлуатаційною ефективністю HR-системи військового обліку. 
2.1.1 Цілі, межі та критерії успішності проєктування. Цілі проєктування 
безпекового контуру в межах HR-системи військового обліку визначаються як 
забезпечення контрольованого, відтворюваного та стійкого доступу до даних і 
функцій системи відповідно до ролей користувачів. Базовою ціллю є не лише технічне 
обмеження доступу, а формування такого архітектурного підходу, за якого будь-яка 
критична операція проходить послідовні етапи перевірки: ідентифікація суб’єкта, 
валідація контексту запиту, перевірка повноважень, фіксація події та контроль 
результату. Таким чином, проєктування орієнтоване на системну керованість 
безпеки, а не на окремі локальні механізми захисту. 
Другою ціллю є досягнення балансу між захищеністю й експлуатаційною 
придатністю системи. Умови практичного використання вимагають, щоб безпекові 
механізми не блокували щоденні операції кадрового підрозділу, але водночас 
гарантовано унеможливлювали несанкціоновані дії. Це означає, що в межах 
проєктування необхідно закласти чітке розмежування доступу до перегляду, 
редагування, імпорту даних, формування документів і службових операцій 
адміністрування. Такий поділ дає змогу мінімізувати ризик надмірних повноважень і 
знижує ймовірність помилкових дій з боку користувачів. 
38 
Третьою ціллю є забезпечення архітектурної узгодженості безпекового контуру 
з клієнт-серверною моделлю системи. Проєктні рішення мають бути придатними для 
REST-взаємодії, коректної роботи десктопного клієнта, обробки асинхронних 
процесів системи та централізованого зберігання даних. У цьому контексті безпека 
розглядається як інтегрована властивість усієї архітектури: від точки входу в систему 
до обробки бізнес-операцій і аудиту подій. 
Межі проєктування визначають функціональну область, у якій реалізуються 
безпекові механізми. До неї входять автентифікація користувачів, рольова 
авторизація, захист серверних API-інтерфейсів, політики допуску до критичних 
операцій, журналювання подій безпеки, а також контрольоване виконання задач 
генерації документів. Поза межами поточного проєктного етапу залишаються, 
зокрема, розширені функції централізованої зовнішньої ідентифікації 
корпоративного рівня, побудова окремого IAM-контуру та спеціалізовані 
криптографічні сервіси підвищеного класу. Таке обмеження є обґрунтованим, 
оскільки ціль поточної роботи полягає у створенні базового, але повноцінного 
контуру безпеки прикладної HR-системи. 
Додатково межі задаються рівнем деталізації проєктування. У межах цього 
підрозділу фіксуються цільові принципи, ролі, логіка доступу, вимоги до взаємодії 
компонентів і критерії результативності; натомість низькорівнева програмна 
реалізація, деталізація коду та тестові сценарії відносяться до наступних розділів 
роботи. Такий поділ відповідає методичній логіці побудови кваліфікаційної роботи 
бакалавра: спочатку формалізується проєктне рішення, потім демонструється його 
практичне впровадження. 
Критерії успішності проєктування мають бути вимірюваними або однозначно 
перевірюваними.  
Перший критерій полягає в тому, що доступ до захищених ресурсів можливий 
виключно після коректної автентифікації й валідації контексту запиту.  
Другий критерій передбачає, що рольова модель доступу однозначно визначає 
допустимі операції для кожної категорії користувачів і не допускає виконання 
критичних дій за відсутності відповідних прав.  
39 
Третій критерій пов’язаний із трасованістю: кожна безпеково значуща 
операція має залишати подію в журналі аудиту з можливістю подальшого аналізу. 
Четвертий критерій успішності стосується процесної надійності: критичні 
операції повинні супроводжуватися фіксацією в журналі аудиту з чіткою прив'язкою 
до суб'єкта, типу дії та результату, із явною обробкою помилок.  
П’ятий критерій визначає інтеграційну узгодженість: клієнтська частина має 
коректно взаємодіяти з безпековим контуром сервера в межах єдиного API-контракту 
без логічних розривів між інтерфейсом і політиками доступу. 
Шостий критерій охоплює експлуатаційний аспект: проєктні рішення повинні 
бути масштабованими, супроводжуваними та придатними до розширення в 
подальших ітераціях розвитку системи. 
2.1.2 Функціональні сценарії та обмеження предметної області. 
Функціональні сценарії в межах проєктування безпекового контуру визначають 
типові та критичні послідовності взаємодії користувачів із HR-системою військового 
обліку. Їх формалізація необхідна для того, щоб проєктні рішення з автентифікації, 
авторизації, захисту API та аудиту були прив’язані не до абстрактних вимог, а до 
реальних операційних процесів. У даній предметній області основну цінність 
становить не сам факт входу в систему, а гарантія того, що кожна наступна дія 
виконується в межах дозволених повноважень і контролюється на рівні архітектури. 
Базовим сценарієм є автентифікований доступ користувача до системи з 
подальшою роботою із захищеними ресурсами. Сценарій включає вхід за обліковими 
даними, отримання токена доступу, додавання токена до запитів клієнта та перевірку 
коректності цього контексту на сервері. Для предметної області військового обліку 
цей сценарій є обов’язковою точкою входу до всіх інших операцій, оскільки 
забезпечує ідентифікацію суб’єкта доступу та створює передумови для коректної 
рольової авторизації. 
Другим груповим сценарієм є робота з реєстром облікових записів: пошук, 
фільтрація, перегляд карток, внесення змін до реквізитів та перевірка узгодженості 
даних. Ці операції мають різний рівень критичності, тому в межах проєктування вони 
розділяються за політиками доступу. Сценарії перегляду допускають ширший спектр 
40 
ролей, тоді як сценарії редагування й масових змін потребують жорсткішого 
контролю, зокрема перевірки прав на серверному рівні для кожного запиту. 
Третім критичним сценарієм є імпорт даних із зовнішніх джерел. У межах 
предметної області військового обліку імпорт впливає на великий обсяг записів, тому 
навіть одинична помилка в структурі файлу або валідації може призвести до 
системних наслідків. Проєктно цей сценарій розглядається як підвищено ризиковий: 
передбачаються перевірка формату, контроль обов’язкових полів, обробка помилок і 
обмеження доступу до операції лише для ролей із відповідними правами. 
Четвертий сценарій стосується аудиту та журналювання подій безпеки і є 
центральним для контрольованості системи. Його специфіка полягає в поєднанні 
безпекових перевірок із фіксацією кожної критичної операції. Система зберігає тип 
дії, цільову сутність, часові параметри та результат операції, забезпечуючи доказову 
базу для подальшого аналізу. У проєктному контурі цей сценарій вимагає надійного 
збереження подій та можливості їх подальшого перегляду і розслідування. 
П’ятим функціональним сценарієм є аудит і аналіз подій безпеки. Він не є 
прямою бізнес-операцією для кінцевого користувача, але є обов’язковим для 
керованості системи. У межах цього сценарію передбачається фіксація спроб входу, 
відмов у доступі, звернень до критичних операцій і результатів критичних операцій. 
Наявність такого сценарію забезпечує простежуваність дій і підвищує здатність 
системи до післяінцидентного аналізу. 
Поряд із сценаріями проєктування враховує обмеження предметної області.  
Перше обмеження пов’язане з регламентованістю даних: облікова інформація 
має чітко визначену структуру, а її коректність безпосередньо впливає на валідність 
сформованих документів. Друге обмеження стосується ролей і зон відповідальності: 
доступ не може надаватися за принципом зручності, а лише за принципом службової 
необхідності. Третє обмеження визначається вимогою до сумісності з клієнт-
серверною архітектурою, що накладає вимоги на єдині контракти взаємодії та 
стандартизовану обробку помилок безпеки. 
Четвертим обмеженням є необхідність збереження продуктивності при 
одночасному посиленні контролю доступу. Надмірна кількість перевірок на 
41 
критичному шляху обробки запитів може погіршити користувацький досвід, тому 
проєктування має забезпечувати достатній рівень безпеки без непропорційного 
операційного навантаження. П’яте обмеження пов’язане з еволюційністю системи: 
модель доступу та безпекові механізми повинні бути розширюваними для майбутніх 
змін ролей, політик і функціональних модулів. 
2.2 Проєктування архітектури модуля контролю доступу 
Архітектура модуля контролю доступу в межах HR-системи військового обліку 
проєктується як наскрізний механізм, інтегрований у клієнт-серверну взаємодію та 
ключові бізнес-процеси системи. Основною ідеєю є централізація перевірок безпеки 
на серверному рівні при збереженні прозорого контракту взаємодії для десктопного 
клієнта. 
У структурі рішення виділяються такі опорні компоненти: контур 
автентифікації, токен-орієнтований механізм підтвердження доступу, рольова 
авторизація, захищені API-ендпоінти, підсистема аудиту подій і контрольований 
процес виконання критичних операцій системи. Взаємодія компонентів побудована 
так, щоб кожний запит до захищених ресурсів проходив послідовну перевірку 
ідентичності та повноважень до передачі в бізнес-логіку. 
Проєктне рішення орієнтоване на безстанову модель доступу [7], що забезпечує 
масштабованість і передбачувану поведінку системи при зростанні навантаження. 
Додатково архітектура враховує вимоги до простежуваності: критичні дії мають 
фіксуватися в журналі подій, а операції підвищеної важливості-супроводжуватися 
фіксацією в журналі аудиту. 
2.2.1 Архітектура взаємодії клієнтської та серверної частин. Архітектура 
взаємодії клієнтської та серверної частин у розроблюваній HR-системі  побудована за 
клієнт-серверною моделлю з розподілом відповідальності між інтерфейсним і 
прикладним рівнями. Клієнтська частина реалізує сценарії взаємодії користувача з 
системою, формує та надсилає запити до серверного API, відображає результати 
операцій і керує станом сесії в межах наданих прав. Серверна частина виконує роль 
центрального вузла обробки: приймає запити, виконує валідацію контексту доступу, 
42 
застосовує рольові політики, обробляє бізнес-операції та повертає стандартизовані 
відповіді. 
Обмін даними організовано через REST-інтерфейс із чітко визначеними 
endpoint’ами та формалізованими структурами запитів/відповідей. Такий підхід 
забезпечує незалежність клієнта від внутрішньої реалізації серверної логіки та 
спрощує масштабування системи. Критично важливим елементом взаємодії є те, що 
будь-який запит до захищених ресурсів розглядається сервером як недовірений до 
моменту перевірки облікового контексту та повноважень користувача. 
Логіка входу до системи реалізується як окремий публічний сценарій: клієнт 
надсилає облікові дані, сервер виконує автентифікацію та повертає маркер доступу. 
Надалі клієнт додає цей маркер до запитів, а серверний фільтр перевіряє його 
валідність перед передачею запиту в прикладний контур. Така модель дозволяє 
відокремити процес встановлення особи від процесу доступу до конкретних функцій, 
а також забезпечує передбачувану поведінку системи при повторюваних зверненнях 
до API. 
Компонентну взаємодію клієнтської та серверної частин у межах безпекового 
контуру наведено на рисунку 2.2. 
 
Рисунок 2.2 – Архітектура взаємодії клієнтської та серверної частин у контурі 
безпеки 
У межах взаємодії підтримуються як синхронні, так і керовані асинхронні 
сценарії. Синхронні сценарії охоплюють типові операції перегляду та редагування 
43 
даних. Асинхронні сценарії передбачають фіксацію критичних операцій у журналі 
аудиту, де сервер зберігає подію з ідентифікатором дії, типом операції та результатом, 
надаючи можливість подальшого аналізу та контролю. Це підвищує стійкість системи 
до збоїв і виключає непрозорі «довгі» операції в одному запиті. 
Важливим аспектом архітектури є узгодженість клієнтського стану з серверною 
політикою доступу. Клієнт може ініціювати лише ті дії, що передбачені 
інтерфейсними сценаріями, однак остаточне рішення про допуск завжди приймається 
сервером. Такий принцип забезпечує єдине джерело істини для правил безпеки та 
мінімізує ризик обходу обмежень через модифікацію клієнтської логіки. 
Тому, архітектура взаємодії клієнтської та серверної частин забезпечує логічно 
узгоджений і безпеково керований обмін даними в HR-системі  військового обліку. 
Вона створює основу для реалізації рольового доступу, захисту API та 
контрольованого виконання критичних операцій без порушення експлуатаційної 
придатності системи. 
2.2.2 Логіка автентифікації, авторизації та захисту API. Логіка 
автентифікації, авторизації та захисту API у проєктованому безпековому контурі 
реалізується як послідовний механізм перевірок, що виконується для кожного запиту 
до захищених ресурсів системи. На концептуальному рівні цей механізм поділяється 
на три взаємопов’язані етапи: встановлення особи користувача, перевірка 
повноважень на виконання дії та контроль доступу до прикладних інтерфейсів 
взаємодії. 
Етап автентифікації ініціюється через публічну точку входу, де користувач 
передає облікові дані. Після успішної перевірки формується маркер доступу з 
обмеженим терміном дії, який надалі використовується клієнтом у зверненнях до 
серверного API. Такий підхід дозволяє уникнути залежності від серверної сесії, 
підтримує масштабованість і забезпечує уніфіковану модель доступу для всіх 
захищених операцій. 
Етап авторизації виконується після підтвердження автентичності запиту та 
базується на рольовій моделі доступу. Роль користувача визначає допустимий перелік 
операцій у системі, а рішення про допуск приймається сервером для кожного запиту 
44 
окремо. У результаті реалізується принцип мінімально необхідних привілеїв: 
користувач отримує лише ті права, які потрібні для виконання його функціональних 
обов’язків. 
Захист API реалізується через розмежування публічного і захищеного 
контурів. До публічного контуру відносяться лише технічно необхідні маршрути, 
пов’язані з входом та службовою інфраструктурою. Решта endpoint’ів працює в 
режимі обов’язкової перевірки контексту доступу. Будь-який запит без валідного 
маркера або з недостатніми повноваженнями повинен завершуватися 
контрольованою відмовою з уніфікованою помилкою без розкриття внутрішніх 
деталей безпекових механізмів. 
Окрему роль у цій логіці відіграє інтеграція з прикладними процесами. Для 
критичних операцій перевірка доступу має поєднуватися з процесними обмеженнями, 
зокрема з контролем станів виконання задач. Це дозволяє запобігати не лише 
несанкціонованому доступу, а й логічно некоректним діям у межах формально 
валідної ролі. 
Для забезпечення керованості та перевірюваності безпекового контуру всі 
значущі події мають фіксуватися в журналі аудиту. У цільовій моделі безпекового 
контуру аудит повинен охоплювати спроби входу, відмови в доступі, звернення до 
критичних endpoint’ів і завершення ключових операцій. Така фіксація є необхідною 
умовою для розслідування інцидентів, контролю відповідності політикам доступу та 
подальшого вдосконалення безпекової моделі. 
2.3 Проєктування моделей доступу, станів і контрактів 
Проєктування моделей доступу, станів і контрактів у межах безпекового 
контуру HR-системи військового обліку спрямоване на формалізацію правил 
функціонування системи на трьох взаємопов’язаних рівнях: рівні повноважень 
користувачів, рівні процесної динаміки критичних операцій та рівні зовнішньої 
взаємодії через API. Такий підхід дає змогу перейти від загальних принципів безпеки 
до чітко визначених, перевірюваних проєктних конструкцій. 
Модель доступу визначає, хто і за яких умов може виконувати конкретні дії в 
45 
системі. Вона повинна забезпечувати рольове розмежування повноважень, 
мінімізацію надлишкових прав та передбачувану обробку сценаріїв відмови в доступі. 
Формалізація цієї моделі створює основу для централізованого керування політиками 
авторизації та унеможливлює довільне трактування прав на рівні окремих 
компонентів. 
Модель аудиту використовується для забезпечення простежуваності операцій 
підвищеної важливості. Її проєктування передбачає визначення типів подій, що 
підлягають фіксації, структури записів аудиту та правил збереження. У результаті 
система отримує контрольований механізм журналювання, що підвищує прозорість 
дій користувачів, забезпечує доказову базу для аналізу інцидентів і покращує 
керованість процесів у реальній експлуатації. 
Контрактна модель взаємодії формалізує обмін даними між клієнтською та 
серверною частинами через API. У межах проєктування визначаються структури 
запитів і відповідей, правила передавання контексту доступу, стандартизовані 
формати повідомлень про помилки та сценарії роботи з асинхронними операціями. 
Це забезпечує узгодженість усіх компонентів системи, зменшує інтеграційні ризики 
та спрощує подальший розвиток функціоналу. 
2.3.1 Рольова модель доступу та матриця прав. Рольова модель доступу в 
проєктованій HR-системі військового обліку базується на принципі Role-Based 
Access Control (RBAC), за яким права доступу призначаються ролям, а не окремим 
користувачам. Такий підхід забезпечує централізованість керування, зменшує ризик 
випадкового накопичення надмірних повноважень і спрощує аудит політик безпеки. 
Для предметної області військового обліку це є критично важливим, оскільки 
система оперує чутливими персональними та службовими даними, а отже доступ до 
них має бути формально регламентованим і відтворюваним. 
Формалізовану матрицю прав доступу для основних операцій наведено в 
таблиці 2.1. 
У межах проєктної постановки доцільно використовувати базову двохрівневу 
модель ролей («користувач» і «адміністратор») як цільову модель розмежування 
повноважень. 
46 
Таблиця 2.1 – Матриця прав доступу за ролями 
Операція Користувач Адміністратор Примітка 
Перегляд реєстру Так Так Доступ для 
студентів автентифікованих 
користувачів 
Перегляд картки Так Так За валідного токена 
студента доступу 
Редагування За політикою Так Уточнюється 
записів студентів серверною 
політикою доступу 
Імпорт даних За політикою Так Критична операція, 
XLSX підвищений 
контроль 
Ініціація генерації За політикою Так Додатково 
документа контролюється 
станами задачі 
Завантаження Так Так За наявності 
згенерованого доступу до taskId 
документа 
Перегляд журналу За політикою Так Рекомендовано 
аудиту обмежити для 
адміністраторів 
Доступ до Ні Так ROLE_ADMIN 
службових 
endpoint (actuator) 
У поточній реалізації системи повна матриця рольових обмежень для всіх 
прикладних операцій ще не формалізована, тому цей підхід розглядається як напрям 
подальшого деталізування політик доступу. 
Формалізація ролей реалізується через матрицю прав доступу, яка відображає 
відповідність між ролями та типами операцій. Матриця повинна охоплювати 
щонайменше такі групи дій: перегляд реєстру, перегляд детальної картки, 
редагування записів, ініціація генерації документів, завантаження результатів, імпорт 
даних, доступ до службових операцій і адміністрування. Використання матриці 
дозволяє уніфікувати правила доступу на етапі проєктування і надалі безпосередньо 
транслювати ці правила в серверні політики авторизації. 
З точки зору безпеки ключовим є застосування принципу deny-by-default [3], за 
47 
яким будь-яка операція вважається забороненою, якщо для ролі явно не визначено 
дозвіл. Це унеможливлює неявне розширення прав і знижує ризик неконтрольованого 
доступу через помилки конфігурації. Додатково в матриці доцільно передбачати 
розмежування між правом ініціювати операцію та правом завершувати або 
підтверджувати її в критичних процесах, що особливо актуально для критичних 
операцій. 
Важливим проєктним аспектом є узгодження матриці прав із прикладними 
станами системи. Рольовий дозвіл сам по собі не повинен гарантувати виконання 
будь-якої дії в будь-який момент часу; для частини операцій необхідно враховувати 
поточний стан об’єкта або задачі. Отже, у проєкті використовується композиційний 
підхід: доступ визначається поєднанням ролі користувача та допустимості операції в 
конкретному процесному контексті. 
Матриця прав також виконує функцію контрольного артефакту для тестування 
та аудиту. На її основі формуються сценарії перевірки успішного доступу, відмови в 
доступі та граничних випадків взаємодії ролей із критичними endpoint’ами. Це 
забезпечує можливість об’єктивно оцінити коректність реалізації політик авторизації 
та підтвердити відповідність безпекового контуру проєктним вимогам. 
2.3.2 Модель аудиту подій та журналювання безпекових операцій. Модель 
аудиту подій у проєктованій HR-системі військового обліку визначає формалізований 
порядок фіксації критичних операцій користувачів із метою забезпечення 
простежуваності, контрольованості та доказовості дій у системі. На відміну від 
підходу, за якого аудит обмежується технічним логуванням у файли серверного 
оточення, запропонована модель базується на персистентному зберіганні 
структурованих записів подій у базі даних із можливістю подальшого аналізу та 
перегляду. 
Структуру моделі аудиту подій подано на рисунку 2.4. 
Логіка моделі передбачає, що при виконанні критичної операції система 
автоматично формує запис аудиту, який містить набір обов'язкових атрибутів: тип дії 
(action), категорію цільової сутності (entityType), ідентифікатор сутності (entityId), 
текстовий опис деталей операції (details) та часову мітку створення (createdAt). 
48 
 
Рисунок 2.4 – Модель аудиту подій у безпековому контурі системи 
Такий набір атрибутів забезпечує однозначну ідентифікацію кожної 
зафіксованої події та створює передумови для відтворення послідовності дій у межах 
конкретного запису або користувача. 
Модель аудиту також узгоджується з безпековим контуром доступу. Право на 
перегляд записів аудиту визначається роллю користувача, а формування записів 
відбувається в межах серверної логіки без можливості втручання з боку клієнта. 
Таким чином, система забезпечує не лише фіксацію подій, а й захист цілісності 
журналу аудиту від несанкціонованих змін. Це особливо важливо для предметної 
області військового обліку, де простежуваність дій є частиною базових вимог 
інформаційної безпеки. 
Важливим елементом моделі є транзакційна цілісність записів аудиту. 
Формування запису відбувається в межах транзакції, що гарантує або повне 
збереження події, або відсутність часткових записів. Для кожної значущої операції 
зберігається інформація, яка забезпечує простежуваність та можливість подальшого 
контролю відповідності політикам безпеки. Це створює доказову основу для 
внутрішнього аудиту та покращення процедур захисту даних системи. 
2.3.3 Проєктування API-контрактів і обробки помилок безпеки. 
Проєктування API-контрактів у межах безпекового контуру HR-системи військового 
обліку виконується за принципом однозначності інтерфейсної взаємодії між 
клієнтською та серверною частинами. Контракт має визначати не лише структуру 
49 
коректних запитів і відповідей, а й правила передавання контексту доступу, очікувані 
стани асинхронних операцій та стандартизовані формати повідомлень про помилки. 
Такий підхід забезпечує передбачувану інтеграцію компонентів системи й зменшує 
ризик неоднозначного трактування бізнес-логіки на рівні клієнта. 
У проєктній моделі всі endpoint’и поділяються на публічні та захищені. 
Публічні маршрути обмежуються технічно необхідним мінімумом, зокрема 
операціями входу до системи та службовими маршрутами інфраструктурного 
призначення. Захищені маршрути вимагають валідного маркера доступу та 
проходження рольової перевірки. Контракт для таких маршрутів повинен явно 
фіксувати вимогу до контексту авторизації, щоб виключити несанкціоноване або 
помилкове використання API. 
Окрема увага в проєктуванні контрактів приділяється захисту критичних API-
операцій, які потребують обов’язкової авторизації та фіксації в журналі аудиту. 
Контракт для таких маршрутів повинен забезпечувати перевірку контексту доступу 
та стандартизовану обробку відмов. 
Стандартизація помилок безпеки є обов’язковою складовою контрактної 
моделі. Для типових ситуацій відмови повинні бути визначені стабільні формати 
відповіді та прогнозована семантика статусів. Це необхідно для того, щоб клієнт 
коректно обробляв відмову, не розкриваючи при цьому користувачеві внутрішніх 
деталей безпекової реалізації. 
З точки зору безпеки критично, щоб повідомлення про помилки залишались 
інформативними для керування сценарієм на клієнті, але не містили даних, які 
можуть спростити зловмиснику аналіз внутрішньої конфігурації системи. Тому, 
проєктування обробки помилок передбачає поділ на зовнішній рівень та внутрішній 
рівень. 
Контрактна модель також має забезпечувати сумісність із механізмами аудиту. 
Значущі помилки безпеки повинні фіксуватися як події, що дозволяє аналізувати 
тенденції відмов, виявляти аномальні патерни доступу та оцінювати стабільність 
політик авторизації. У результаті API-контракти стають не лише інтерфейсом обміну 
даними, а й інструментом керованості безпекового контуру в експлуатації. 
50 
Висновки до розділу 2 
У межах розділу виконано проєктне опрацювання модуля контролю доступу та 
базової безпеки для HR-системи військового обліку на рівні архітектурних рішень, 
моделей доступу, процесних станів і контрактів взаємодії. Сформовано цілі та межі 
проєктування, визначено критерії успішності, обґрунтовано ключові функціональні 
сценарії. 
За результатами проєктування встановлено, що цільова архітектура повинна 
поєднувати клієнт-серверну модель взаємодії, централізовану перевірку доступу на 
серверному рівні, рольове розмежування повноважень і керовану обробку критичних 
операцій. Такий підхід дозволяє реалізувати принцип мінімально необхідних 
привілеїв, зменшити ризик несанкціонованих дій і забезпечити узгодженість між 
прикладною логікою та безпековими політиками. 
Окремо обґрунтовано доцільність використання моделі аудиту подій як 
механізму забезпечення простежуваності. Фіксація критичних операцій у журналі 
забезпечує прозорість дій користувачів, доказову базу для аналізу інцидентів та 
підвищення надійності безпекового контуру. Водночас, проєктування API-контрактів 
і уніфікованої обробки помилок безпеки створює передумови для стабільної 
інтеграції клієнтської та серверної частин і знижує експлуатаційні ризики. 
Тому, в розділі  сформовано цілісну проєктну основу реалізації безпекового 
контуру, яка узгоджує архітектурні, функціональні та процесні вимоги предметної 
області військового обліку. Отримані результати є достатніми для переходу до 
наступного розділу, присвяченого практичній реалізації рішень, їх верифікації та 
оцінюванню працездатності в прикладних сценаріях.  
51 
3 ПРОГРАМНА РЕАЛІЗАЦІЯ МОДУЛЯ КОНТРОЛЮ ДОСТУПУ ТА 
БАЗОВОЇ БЕЗПЕКИ 
3.1 Реалізація механізмів автентифікації та захисту API 
Програмна реалізація механізмів автентифікації та захисту API у HR-системі 
військового обліку виконана на основі проєктних рішень, обґрунтованих у розділі 2, 
із використанням фреймворку Spring Security [7] як базового інструменту побудови 
безпекового контуру серверної частини. Основним завданням реалізації є 
забезпечення контрольованого доступу до захищених ресурсів системи через 
механізм stateless-автентифікації на основі JWT-токенів [5] та рольову модель 
авторизації. 
У межах підрозділу розглядається програмна реалізація трьох ключових 
компонентів: конфігурація безпекового контуру серверного застосунку, реалізація 
утиліти генерації та валідації JWT-токенів, а також реалізація фільтра перехоплення 
HTTP-запитів для перевірки контексту доступу. Кожен із цих компонентів виконує 
окрему функцію в загальному ланцюзі обробки запиту, однак працює як частина 
єдиного безпекового контуру, що забезпечує наскрізну перевірку автентичності та 
повноважень користувача. 
Реалізація побудована за принципом розділення відповідальності: контролер 
автентифікації відповідає за публічну точку входу, сервіс автентифікації – за 
координацію перевірки облікових даних та формування токена, утиліта JWT – за 
криптографічні операції з токенами, а фільтр – за перехоплення кожного HTTP-
запиту та встановлення контексту безпеки. Така декомпозиція відповідає принципам 
SOLID і забезпечує тестованість та розширюваність кожного компонента окремо. 
Конфігурація Spring Security визначає загальну політику доступу до ресурсів, 
включаючи перелік публічних маршрутів, правила авторизації для захищених 
endpoint'ів, політику керування сесіями (stateless) та порядок підключення JWT-
фільтра до ланцюга обробки запитів. Водночас конфігурація передбачає 
використання BCrypt-алгоритму для хешування паролів, що унеможливлює 
збереження облікових даних у відкритому вигляді. 
52 
Механізм JWT-автентифікації реалізується через генерацію підписаного токена 
після успішного входу та його подальшу валідацію на кожному запиті до захищених 
ресурсів. Токен містить ідентифікатор користувача (subject), часові параметри (дати 
створення та закінчення дії) і підписується секретним ключем на основі алгоритму 
HMAC-SHA. Валідація включає перевірку підпису, терміну дії та відповідності 
ідентифікатора наявному обліковому запису в базі даних. 
Фільтр автентифікації інтегрований у ланцюг обробки Spring Security і 
виконується перед стандартним фільтром UsernamePasswordAuthenticationFilter. Це 
дозволяє перехоплювати кожен вхідний HTTP-запит, витягувати JWT-токен із 
заголовка Authorization, виконувати його валідацію та, за умови успіху, 
встановлювати об'єкт автентифікації в SecurityContext. Завдяки цьому подальша 
обробка запиту в контролерах і сервісах відбувається з уже встановленим контекстом 
безпеки, що забезпечує прозорість перевірки доступу на всіх рівнях. 
Подальші пункти підрозділу конкретизують реалізацію кожного компонента 
через аналіз вихідного коду та пояснення прийнятих рішень. 
3.1.1 Конфігурація Spring Security та рольова політика доступу. 
Конфігурація Spring Security є центральним елементом безпекового контуру 
серверного застосунку, що визначає загальну політику доступу до ресурсів, порядок 
автентифікації користувачів і стратегію керування сесіями. У реалізованій HR-
системі військового обліку конфігурація виконана у вигляді окремого класу 
SecurityConfig, анотованого @Configuration та @EnableWebSecurity, що забезпечує 
декларативне налаштування безпекового ланцюга Spring Security [7]. 
Основним компонентом конфігурації є метод securityFilterChain, який формує 
ланцюг безпекових фільтрів (SecurityFilterChain) для обробки HTTP-запитів. 
Ключовий фрагмент реалізації наведено в лістингу 3.1. 
Лістинг 3.1 – Конфігурація ланцюга безпекових фільтрів (SecurityConfig.java): 
@Bean 
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception 
{ 
    http 
53 
            .csrf(AbstractHttpConfigurer::disable) 
            .authorizeHttpRequests(auth -> auth 
                    .requestMatchers("/api/v1/auth/**").permitAll() 
                    .requestMatchers("/v3/api-docs/**", "/swagger-ui/**", 
                            "/swagger-ui.html") 
                    .permitAll() 
                    .requestMatchers("/actuator/health").permitAll() 
                    .requestMatchers("/actuator/**").hasRole("ADMIN") 
                    .anyRequest().authenticated()) 
            .sessionManagement(session -> session 
                    .sessionCreationPolicy(SessionCreationPolicy.STATELESS)) 
            .authenticationProvider(authenticationProvider()) 
            .addFilterBefore(jwtAuthFilter, 
                    UsernamePasswordAuthenticationFilter.class); 
    return http.build(); 
} 
У наведеному лістингу реалізовано декілька принципових рішень, кожне з яких 
обумовлене проєктними вимогами, визначеними у розділі 2. 
По-перше, вимкнено механізм CSRF (Cross-Site Request Forgery) через виклик 
csrf(AbstractHttpConfigurer::disable). Це рішення є обґрунтованим для REST API, 
оскільки взаємодія відбувається через десктопний клієнт із передачею токена в 
заголовку Authorization, а не через браузерні форми з cookie-автентифікацією. У такій 
архітектурі CSRF-захист є надлишковим і може спричинити помилкові відмови в 
доступі. 
По-друге, визначено розмежування публічних і захищених маршрутів. 
Публічними залишаються лише технічно необхідні endpoint'и: маршрут 
автентифікації (/api/v1/auth/), документація API (Swagger UI) та перевірка стану 
сервісу (/actuator/health). Маршрути моніторингу (/actuator/) обмежені роллю ADMIN, 
що забезпечує рольовий контроль доступу до службової інформації. Усі інші запити 
вимагають обов'язкової автентифікації через правило anyRequest().authenticated(), що 
54 
реалізує принцип deny-by-default [3]. 
По-третє, встановлено безстанову політику сесій 
(SessionCreationPolicy.STATELESS). Це означає, що сервер не створює і не зберігає 
HTTP-сесій, а кожен запит повинен містити власний контекст автентифікації у 
вигляді JWT-токена. Такий підхід забезпечує горизонтальну масштабованість та 
відповідає архітектурним принципам REST-взаємодії [9]. 
По-четверте, у ланцюг фільтрів додано власний JwtAuthenticationFilter, який 
виконується перед стандартним UsernamePasswordAuthenticationFilter. Це дозволяє 
перехопити запит на ранньому етапі обробки, витягти та валідувати токен і 
встановити контекст безпеки до передачі запиту в контролер. 
Окремим компонентом конфігурації є налаштування провайдера автентифікації 
та кодувальника паролів. У лістингу 3.2 наведено реалізацію цих компонентів. 
Лістинг 3.2 – Конфігурація провайдера автентифікації та BCrypt 
(SecurityConfig.java): 
@Bean 
public AuthenticationProvider authenticationProvider() { 
    DaoAuthenticationProvider authProvider = new DaoAuthenticationProvider(); 
    authProvider.setUserDetailsService(userDetailsService); 
    authProvider.setPasswordEncoder(passwordEncoder()); 
    return authProvider; 
} 
 
@Bean 
public PasswordEncoder passwordEncoder() { 
    return new BCryptPasswordEncoder(); 
} 
DaoAuthenticationProvider забезпечує перевірку облікових даних через зв'язку з 
CustomUserDetailsService, який виконує пошук користувача в базі даних, та 
BCryptPasswordEncoder, який здійснює перевірку хешу пароля. Використання 
BCrypt-алгоритму гарантує, що паролі зберігаються у базі даних виключно у 
55 
хешованому вигляді з адаптивною складністю, що унеможливлює їх відновлення 
навіть за умови компрометації бази даних. 
Для забезпечення зв'язку між Spring Security та доменною моделлю 
користувачів реалізовано CustomUserDetailsService, який імплементує інтерфейс 
UserDetailsService. Даний сервіс виконує пошук облікового запису за ім'ям 
користувача (username) у таблиці app_users через UserRepository та формує об'єкт 
UserDetails із зазначенням ролі користувача як авторитету доступу 
(SimpleGrantedAuthority). Це забезпечує прозорий механізм визначення повноважень 
користувача на етапі автентифікації. 
Доменна модель облікового запису представлена сутністю AppUser, яка 
зберігається в таблиці app_users і містить такі атрибути: ідентифікатор (id), ім'я 
користувача (username), хеш пароля (passwordHash) та роль (role). Мінімалістична 
структура моделі обумовлена поточним етапом розвитку системи, який передбачає 
базову двохрівневу модель ролей (ROLE_USER та ROLE_ADMIN). 
Для забезпечення початкової працездатності системи реалізовано компонент 
AuthUserSeeder, який автоматично створює або оновлює обліковий запис 
адміністратора при запуску застосунку. Сідер перевіряє наявність запису, і за його 
відсутності створює нового користувача з роллю ROLE_ADMIN та хешованим 
паролем. Це гарантує, що система завжди має щонайменше один активний обліковий 
запис для доступу. 
Таким чином, конфігурація Spring Security забезпечує комплексне 
налаштування безпекового контуру: визначення політики доступу, підключення 
JWT-фільтра, налаштування провайдера автентифікації з BCrypt-хешуванням та 
інтеграцію з доменною моделлю користувачів. Усі рішення відповідають проєктним 
вимогам, сформульованим у підрозділі 2.2. 
3.1.2 Реалізація JWT-автентифікації (генерація, валідація, фільтрація). 
Процес JWT-автентифікації у реалізованій системі охоплює три послідовні етапи: 
вхід користувача з генерацією токена, валідація токена на кожному запиті та 
встановлення контексту безпеки через фільтр. Кожен етап реалізовано окремим 
компонентом, що забезпечує чітке розділення відповідальності. 
56 
Точкою входу є AuthController, який приймає POST-запит на /api/v1/auth/login 
із обліковими даними та делегує обробку сервісу AuthService. Реалізацію процесу 
логіну наведено в лістингу 3.3. 
Лістинг 3.3 – Сервіс автентифікації (AuthService.java): 
@Service 
public class AuthService { 
 
    private final AuthenticationManager authenticationManager; 
    private final CustomUserDetailsService userDetailsService; 
    private final JwtUtil jwtUtil; 
 
    public LoginResponse login(LoginRequest request) { 
        authenticationManager.authenticate( 
                new UsernamePasswordAuthenticationToken( 
                        request.getUsername(), request.getPassword())); 
 
        UserDetails userDetails = userDetailsService 
                .loadUserByUsername(request.getUsername()); 
        String token = jwtUtil.generateToken(userDetails); 
        return new LoginResponse(token); 
    } 
} 
AuthenticationManager виконує перевірку пари логін/пароль через 
DaoAuthenticationProvider із BCrypt-порівнянням хешів. У разі невдалої 
автентифікації Spring Security автоматично генерує виняток, що повертає клієнту 
відповідь 401 Unauthorized. Після успішної перевірки сервіс завантажує повний 
контекст користувача та передає його утиліті JwtUtil для генерації токена. 
Генерацію та валідацію JWT-токенів реалізовано в класі JwtUtil [5]. Ключові 
методи наведено в лістингу 3.4. 
Лістинг 3.4 – Генерація та валідація JWT-токенів (JwtUtil.java): 
57 
@Component 
public class JwtUtil { 
    @Value("${jwt.secret}") 
    private String secret; 
    @Value("${jwt.expiration}") 
    private long jwtExpiration; 
    private String createToken(Map<String, Object> claims, String subject) { 
        return Jwts.builder() 
                .claims(claims) 
                .subject(subject) 
                .issuedAt(new Date(System.currentTimeMillis())) 
                .expiration(new Date(System.currentTimeMillis() + jwtExpiration)) 
                .signWith(getSigningKey()) 
                .compact(); 
    } 
    public Boolean validateToken(String token, UserDetails userDetails) { 
        final String username = extractUsername(token); 
        return (username.equals(userDetails.getUsername()) 
                && !isTokenExpired(token)); 
    } 
    private SecretKey getSigningKey() { 
        byte[] keyBytes = secret.getBytes(StandardCharsets.UTF_8); 
        return Keys.hmacShaKeyFor(keyBytes); 
    } 
} 
Секретний ключ та термін дії токена винесені у зовнішню конфігурацію 
(application.yml), що дозволяє змінювати їх без перекомпіляції. Підпис виконується 
алгоритмом HMAC-SHA через бібліотеку jjwt. Валідація перевіряє відповідність 
subject та термін дії токена. 
Перехоплення та обробку токена на кожному запиті реалізовано у 
58 
JwtAuthenticationFilter, який наслідує OncePerRequestFilter. Логіку фільтра наведено в 
лістингу 3.5. 
Лістинг 3.5 – Фільтр JWT-автентифікації (JwtAuthenticationFilter.java): 
@Component 
public class JwtAuthenticationFilter extends OncePerRequestFilter { 
    @Override 
    protected void doFilterInternal(HttpServletRequest request, 
            HttpServletResponse response, FilterChain filterChain) 
            throws ServletException, IOException { 
        final String authHeader = request.getHeader("Authorization"); 
        String username = null; 
        String jwt = null; 
        if (StringUtils.isNotBlank(authHeader) 
                && authHeader.startsWith("Bearer ")) { 
            jwt = authHeader.substring(7); 
            try { 
                username = jwtUtil.extractUsername(jwt); 
            } catch (Exception e) { 
                logger.warn("JWT extraction failed: " + e.getMessage()); 
            } 
        } 
        if (StringUtils.isNotBlank(username) && SecurityContextHolder 
                .getContext().getAuthentication() == null) { 
            UserDetails userDetails = this.userDetailsService 
                    .loadUserByUsername(username); 
            if (jwtUtil.validateToken(jwt, userDetails)) { 
                UsernamePasswordAuthenticationToken authToken = 
                        new UsernamePasswordAuthenticationToken( 
                                userDetails, null, 
                                userDetails.getAuthorities()); 
59 
                authToken.setDetails( 
                        new WebAuthenticationDetailsSource() 
                                .buildDetails(request)); 
                SecurityContextHolder.getContext() 
                        .setAuthentication(authToken); 
            } 
        } 
        filterChain.doFilter(request, response); 
    } 
} 
Фільтр витягує токен із заголовка Authorization (з префіксом "Bearer "), виконує 
його валідацію через JwtUtil і, за умови успіху, створює об'єкт 
UsernamePasswordAuthenticationToken з авторитетами ролі та встановлює його в 
SecurityContextHolder. Якщо токен відсутній, прострочений або невалідний, фільтр 
пропускає запит далі без встановлення контексту, і Spring Security автоматично 
відхиляє доступ до захищених маршрутів. 
Таким чином, реалізація JWT-автентифікації забезпечує повний цикл 
безпечного доступу: від входу з генерацією токена до його валідації на кожному 
запиті, що відповідає проєктним вимогам stateless-автентифікації, визначеним у 
підрозділі 2.2.2. 
3.2 Реалізація підсистеми аудиту подій безпеки 
Підсистема аудиту подій безпеки реалізована як окремий модуль серверного 
застосунку, що забезпечує автоматичну фіксацію критичних операцій користувачів у 
базі даних. Відповідно до проєктних рішень, обґрунтованих у підрозділі 2.3.2, 
підсистема побудована на основі доменної сутності AuditLog, репозиторію для 
персистентного збереження та сервісного компонента, який інтегрується з бізнес-
процесами системи. 
Реалізація аудиту охоплює фіксацію операцій генерації документів із 
прив'язкою до конкретного студента, типу документа та часових параметрів. Такий 
60 
підхід забезпечує простежуваність дій та формує доказову базу для аналізу 
інцидентів, що є вимогою стандарту ISO/IEC 27001 [4]. 
У подальших пунктах підрозділу розглядається структура доменної моделі 
аудиту та її інтеграція з бізнес-логікою системи. 
3.2.1 Доменна модель та персистентність записів аудиту. Доменна модель 
аудиту представлена JPA-сутністю AuditLog, яка відображається на таблицю 
audit_log у базі даних PostgreSQL [6]. Структуру сутності наведено в лістингу 3.6. 
Лістинг 3.6 – Доменна модель запису аудиту (AuditLog.java): 
@Entity 
@Table(name = "audit_log") 
public class AuditLog { 
    @Id 
    @GeneratedValue(strategy = GenerationType.IDENTITY) 
    private Long id; 
    @Column(nullable = false, length = 100) 
    private String action; 
    @Column(name = "entity_type", nullable = false, length = 50) 
    private String entityType; 
    @Column(name = "entity_id") 
    private Long entityId; 
    @Column(columnDefinition = "TEXT") 
    private String details; 
    @Column(name = "created_at", nullable = false) 
    private LocalDateTime createdAt; 
    @PrePersist 
    protected void onCreate() { 
        createdAt = LocalDateTime.now(); 
    } 
    public AuditLog(String action, String entityType, 
                    Long entityId, String details) { 
61 
        this.action = action; 
        this.entityType = entityType; 
        this.entityId = entityId; 
        this.details = details; 
    } 
} 
Сутність містить п'ять ключових атрибутів, кожен з яких відповідає проєктній 
моделі аудиту. Атрибут action визначає тип операції (наприклад, 
DOCUMENT_GENERATED). Атрибут entityType вказує категорію цільової сутності 
(Student), а entityId – її ідентифікатор у базі даних. Поле details зберігає текстовий 
опис операції, що дозволяє фіксувати контекстну інформацію (наприклад, тип 
згенерованого документа). Поле createdAt заповнюється автоматично через механізм 
@PrePersist при збереженні запису, що гарантує точність часових параметрів без 
залежності від прикладного коду. 
Персистентність забезпечується через AuditLogRepository, який наслідує 
JpaRepository та надає методи пошуку записів за типом сутності та ідентифікатором 
із сортуванням за часом створення. Це дозволяє отримувати журнал подій як для 
конкретного студента, так і загальний перелік усіх операцій. 
Обрана структура є розширюваною: додавання нових типів дій або категорій 
сутностей не потребує зміни схеми бази даних, оскільки атрибути action та entityType 
реалізовані як текстові поля. 
3.2.2 Сервіс аудиту та інтеграція з бізнес-процесами. Сервісний компонент 
AuditService забезпечує програмний інтерфейс для створення записів аудиту та їх 
отримання. Реалізацію сервісу наведено в лістингу 3.7. 
Лістинг 3.7 – Сервіс аудиту подій (AuditService.java): 
@Slf4j 
@Service 
@RequiredArgsConstructor 
public class AuditService { 
    private static final String ACTION_DOCUMENT_GENERATED = 
62 
            "DOCUMENT_GENERATED"; 
    private static final String ENTITY_TYPE_STUDENT = "Student"; 
    private static final String DOCUMENT_GENERATION_DETAIL_TEMPLATE 
= 
            "Generated document: %s"; 
    private final AuditLogRepository auditLogRepository; 
    @Transactional 
    public void logDocumentGeneration(Long studentId, 
                                      DocumentType documentType) { 
        String details = String.format( 
                DOCUMENT_GENERATION_DETAIL_TEMPLATE, 
                documentType.getDisplayName()); 
        AuditLog auditLog = new AuditLog( 
                ACTION_DOCUMENT_GENERATED, 
                ENTITY_TYPE_STUDENT, 
                studentId, 
                details); 
        auditLogRepository.save(auditLog); 
        log.info("Audit log created: {} for student {}", 
                documentType, studentId); 
    } 
    @Transactional(readOnly = true) 
    public List<AuditLog> getAuditLogsForStudent(Long studentId) { 
        return auditLogRepository 
                .findByEntityTypeAndEntityIdOrderByCreatedAtDesc( 
                        ENTITY_TYPE_STUDENT, studentId); 
    } 
    @Transactional(readOnly = true) 
    public List<AuditLog> getAllAuditLogs() { 
        return auditLogRepository.findAllByOrderByCreatedAtDesc(); 
63 
    } 
} 
Метод logDocumentGeneration викликається з бізнес-логіки генерації 
документів і виконується в межах транзакції (@Transactional). Це гарантує 
атомарність збереження: запис аудиту або зберігається повністю, або не зберігається 
взагалі, що виключає часткові чи неконсистентні записи. Типи дій та категорії 
сутностей визначені як константи, що забезпечує однорідність записів у журналі та 
спрощує їх подальший аналіз. 
Сервіс також надає два методи читання: getAuditLogsForStudent для отримання 
журналу подій конкретного студента та getAllAuditLogs для загального переліку. 
Обидва методи позначені @Transactional(readOnly = true), що оптимізує роботу з 
базою даних для операцій читання. Сортування за полем createdAt у спадному 
порядку забезпечує хронологічно зворотне відображення подій, що є зручним для 
оперативного аналізу останніх дій. 
Інтеграція аудиту з бізнес-процесами реалізована на рівні сервісного шару: при 
генерації документа відповідний сервіс викликає метод logDocumentGeneration, 
передаючи ідентифікатор студента та тип документа. Таким чином, підсистема 
аудиту працює прозоро для решти компонентів системи, не ускладнюючи основну 
бізнес-логіку. 
 3.3 Тестування та верифікація модуля безпеки 
Тестування та верифікація модуля контролю доступу є завершальним етапом 
реалізації, що дозволяє підтвердити коректність роботи безпекових механізмів у 
реальних сценаріях використання. Перевірка охоплює як автоматизоване 
функціональне тестування окремих компонентів, так і наскрізну демонстрацію 
роботи модуля в інтегрованому середовищі. 
Функціональне тестування спрямоване на перевірку ключових сценаріїв 
автентифікації, авторизації та аудиту: успішний вхід, відмова при невірних облікових 
даних, доступ без токена, доступ із протермінованим токеном, рольове обмеження 
маршрутів та фіксація операцій у журналі аудиту. Кожен сценарій перевіряється на 
64 
відповідність очікуваному результату відповідно до проєктних вимог підрозділу 2.1. 
Демонстрація роботи модуля виконується через візуальне підтвердження 
функціонування системи: екрани десктопного клієнта, результати API-запитів та 
записи у базі даних. Подальші пункти підрозділу деталізують результати тестування 
та наводять екранні форми роботи модуля. 
3.3.1 Результати функціонального тестування. Функціональне тестування 
модуля контролю доступу виконано на основі набору тестових сценаріїв, що 
охоплюють ключові варіанти взаємодії з безпековим контуром системи. Кожен 
сценарій перевіряє конкретний аспект автентифікації, авторизації або аудиту і 
порівнює фактичний результат із очікуваним. Результати тестування наведено в 
таблиці 3.1. 
Таблиця 3.1 – Результати функціонального тестування модуля безпеки 
№ Тестовий Вхідні дані Очікуваний Фактичний 
сценарій результат результат 
1 Логін з username: 200 OK, JWT- Відповідає 
коректними admin123, токен у 
обліковими password: відповіді 
даними admin123 
2 Логін з невірним username: 401 Відповідає 
паролем admin123, Unauthorized 
password: 
wrong 
3 Логін з username: 401 Відповідає 
неіснуючим unknown, Unauthorized 
користувачем password: any 
4 Запит до GET 403 Forbidden Відповідає 
захищеного /api/v1/students, 
endpoint без без 
токена Authorization 
5 Запит із GET 200 OK, дані у Відповідає 
валідним /api/v1/students, відповіді 
токеном Bearer 
[valid_token] 
6 Запит із GET 403 Forbidden Відповідає 
протермінованим /api/v1/students, 
токеном Bearer 
[expired_token] 
7 Доступ до GET 403 Forbidden Відповідає 
65 
actuator без ролі /actuator/info, 
ADMIN Bearer 
[user_token] 
8 Генерація POST Документ Відповідає 
документа з генерація згенеровано, 
фіксацією аудиту документа для запис у 
студента audit_log 
створено 
 
Усі вісім тестових сценаріїв підтвердили відповідність фактичної поведінки 
системи очікуваним результатам. Сценарії 1–3 перевіряють коректність механізму 
автентифікації: система успішно видає токен при правильних облікових даних і 
повертає помилку 401 при невірних. Сценарії 4–6 підтверджують роботу JWT-
фільтра: запити без токена або з невалідним токеном відхиляються, а запити з дійсним 
токеном обробляються коректно. Сценарій 7 перевіряє рольове обмеження доступу 
до службових маршрутів. Сценарій 8 підтверджує інтеграцію підсистеми аудиту з 
бізнес-процесом генерації документів. 
Результати тестування підтверджують, що реалізований модуль контролю 
доступу забезпечує надійну автентифікацію, коректну авторизацію та фіксацію 
критичних операцій відповідно до проєктних вимог. 
3.3.2 Демонстрація роботи модуля. Для наочного підтвердження 
працездатності реалізованого модуля контролю доступу наведено екранні форми 
ключових сценаріїв роботи системи. 
На рисунку 3.1 представлено екран автентифікації десктопного клієнта HR-
системи. Користувач вводить логін та пароль, після чого клієнт надсилає POST-запит 
до /api/v1/auth/login. У разі успішної автентифікації клієнт отримує JWT-токен і 
переходить до головного екрану системи. 
На рисунку 3.2 показано головний екран системи після успішного входу. 
Користувач має доступ до реєстру студентів, функцій пошуку та фільтрації. Усі 
запити до серверного API виконуються з автоматичним додаванням JWT-токена в 
заголовок Authorization. 
 
66 
 
Рисунок 3.1 – Екран автентифікації в десктопному клієнті 
 
Рисунок 3.2 – Головний екран системи після автентифікації 
На рисунку 3.3 продемонстровано результат спроби доступу до захищеного 
ресурсу без валідного токена. Сервер повертає відповідь 403 Forbidden, що 
підтверджує коректність роботи JWT-фільтра та принципу deny-by-default. 
67 
 
Рисунок 3.3 – Відмова в доступі при невалідному токені 
На рисунку 3.4 наведено журнал аудиту подій, що фіксує операції генерації 
документів із зазначенням типу дії, ідентифікатора студента та часу виконання. 
Записи відображаються у хронологічному порядку, що забезпечує оперативний 
аналіз останніх дій користувачів. 
 
Рисунок 3.4 – Журнал аудиту подій безпеки 
Наведені екранні форми підтверджують, що реалізований модуль контролю 
доступу та базової безпеки функціонує відповідно до проєктних вимог і забезпечує 
контрольований доступ до ресурсів HR-системи військового обліку. 
Висновки до розділу 3 
У межах розділу виконано програмну реалізацію модуля контролю доступу та 
базової безпеки в HR-системі військового обліку на основі проєктних рішень, 
68 
обґрунтованих у розділі 2.  
Реалізовано конфігурацію Spring Security із безстановою політикою сесій, JWT-
автентифікацію з генерацією та валідацією токенів, фільтр перехоплення HTTP-
запитів для встановлення контексту безпеки, а також підсистему аудиту подій із 
транзакційним збереженням записів у базі даних PostgreSQL. 
За результатами функціонального тестування підтверджено коректність роботи 
всіх ключових сценаріїв: успішна та неуспішна автентифікація, контроль доступу на 
рівні маршрутів, рольове обмеження службових endpoint'ів, валідація та відхилення 
невалідних токенів, а також фіксація критичних операцій у журналі аудиту. Усі вісім 
тестових сценаріїв продемонстрували відповідність фактичної поведінки системи 
очікуваним результатам. 
Отже, програмна реалізація безпекового контуру відповідає визначеним 
функціональним і нефункціональним вимогам та підтверджує практичну придатність 
обраних архітектурних рішень для забезпечення контрольованого доступу до 
ресурсів HR-системи військового обліку. 
  
69 
ВИСНОВКИ 
У кваліфікаційній роботі бакалавра виконано проєктування та програмну 
реалізацію модуля контролю доступу та базової безпеки в HR-системі військового 
обліку. За результатами роботи досягнуто поставлену мету та виконано всі 
сформульовані завдання: 
1. Проведено аналіз предметної області HR-системи військового обліку та 
визначено ключові ризики інформаційної безпеки: несанкціонований доступ до 
персональних даних, порушення цілісності облікової інформації, недостатня 
простежуваність дій користувачів та відсутність контрольованого розмежування 
повноважень. 
2. Проаналізовано сучасні підходи до автентифікації, авторизації, рольового 
розмежування доступу й аудиту подій. Виконано порівняльний аналіз сесійного 
підходу, непрозорих токенів та JWT-автентифікації у поєднанні з RBAC. 
Обґрунтовано вибір безстанової моделі на основі JWT як найбільш придатної для 
клієнт-серверної архітектури проєкту. 
3. Обґрунтовано архітектурні принципи побудови модуля контролю доступу: 
наскрізний безпековий контур, розділення публічних і захищених маршрутів, 
принцип deny-by-default, stateless-політика сесій та інтеграція аудиту з бізнес-
процесами. 
4. Реалізовано механізми безпечного входу, перевірки токенів та захисту API-
запитів на базі Spring Security. Конфігурація включає JWT-фільтр, BCrypt-хешування 
паролів, рольове обмеження маршрутів та безстанову політику сесій. 
5. Реалізовано модуль безпеки API та систему аудиту подій (Audit Log) із 
коректною обробкою помилок безпеки. Підсистема аудиту забезпечує транзакційне 
збереження записів про критичні операції з прив'язкою до типу дії, цільової сутності 
та часових параметрів. 
6. Реалізовано базовий аудит дій користувачів і подій безпеки через сервісний 
компонент AuditService, інтегрований із процесом генерації документів. Журнал 
аудиту зберігається в базі даних PostgreSQL і доступний для аналізу. 
70 
7. Забезпечено узгодження безпекового контуру серверної і клієнтської частин 
через єдиний контракт REST API з передачею JWT-токена в заголовку Authorization. 
8. Виконано перевірку працездатності реалізованих рішень на тестових 
сценаріях. Функціональне тестування підтвердило коректність роботи 
автентифікації, авторизації, рольового обмеження доступу та фіксації операцій у 
журналі аудиту. 
Практичне значення одержаних результатів полягає в тому, що реалізований 
модуль може бути безпосередньо використаний у робочому контурі HR-системи для 
обмеження несанкціонованого доступу, забезпечення керованого розмежування 
повноважень, підвищення прозорості дій користувачів та формування основи для 
подальшого розвитку безпекових механізмів. 
  
71 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. OWASP Foundation. OWASP Top Ten – 2021. URL: https://owasp.org/www-
project-top-ten/ (дата звернення: 15.03.2026). 
2.  Sandhu R., Ferraiolo D., Kuhn R. The NIST Model for Role-Based Access 
Control: Towards a Unified Standard. Proc. 5th ACM Workshop on Role-Based Access 
Control. 2000. P. 47–63. 
3. NIST SP 800-162. Guide to Attribute Based Access Control (ABAC) Definition 
and Considerations. National Institute of Standards and Technology. 2014. 54 p. 
4. ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection 
– Information security management systems – Requirements. International Organization for 
Standardization. 2022. 
5.  Jones M., Bradley J., Sakimura N. RFC 7519: JSON Web Token (JWT). Internet 
Engineering Task Force (IETF). 2015. URL: https://datatracker.ietf.org/doc/html/rfc7519 
(дата звернення: 10.04.2026). 
6.  PostgreSQL 16 Documentation. The PostgreSQL Global Development Group. 
URL: https://www.postgresql.org/docs/16/ (дата звернення: 14.03.2026). 
7. Spring Security Reference Documentation. VMware, Inc. URL: 
https://docs.spring.io/spring-security/reference/ (дата звернення: 12.03.2026). 
8. Методичні рекомендації для підготовки кваліфікаційної роботи бакалавра 
здобувачів освітнього ступеня «бакалавр» зі спеціальності 122 (F3) – «Комп'ютерні 
науки» усіх форм навчання [Електронний ресурс] / [упоряд. Триус Ю.В., Оксамитна 
Л.П., Підгорний М.В.]; М-во освіти і науки України, Черкас. держ. технол. ун-т. 
Черкаси: ЧДТУ, 2026. 53 с. 
9. Spring Boot Reference Documentation. VMware, Inc. URL: 
https://docs.spring.io/spring-boot/docs/current/reference/html/ (дата звернення: 
12.03.2026). 
10. Закон України «Про захист персональних даних» від 01.06.2010 № 2297-VI. 
Відомості Верховної Ради України. 2010. № 34. Ст. 481. 
11. Kotlin Multiplatform Documentation. JetBrains s.r.o. URL: 
72 
https://kotlinlang.org/docs/multiplatform.html (дата звернення: 20.03.2026). 
12. JetBrains. Compose Multiplatform. URL: 
https://www.jetbrains.com/lp/compose-multiplatform/ (дата звернення: 20.03.2026). 
13. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л. П. 
Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована HR-
система закладу вищої освіти  : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.]; 
Міністерство освіти і науки України, Черкаський державний технологічний ун-т.  
Черкаси : ЧДТУ, 2026. С. 14. 
 
  
73 
ДОДАТОК А 
 
 
 
        Затверджую               
Зав. кафедри КНСА, 
______________ Юрій ТРИУС 
«____»____________2026 р.                                                                                                                                                                              
 
 
 
 
 
 
 
МОДУЛЬ КОНТРОЛЮ ДОСТУПУ ТА БАЗОВОЇ БЕЗПЕКИ В HR-СИСТЕМІ 
ВІЙСЬКОВОГО ОБЛІКУ 
 
 
Специфікація  
482.ЧДТУ. 62289-01 
 
Листів 2 
 
 
 
Розробник                          ____________________                Дмитро КЄРНУС 
 
Керівник                             ____________________                Любов ОКСАМИТНА 
 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси – 2026  
74 
482.ЧДТУ. 62289-01 
 
Позначення Найменування Примітка 
   
   
 Документація  
   
   
482.ЧДТУ. 62289-01    12 01 Текст програми  
482.ЧДТУ. 62289-01    34 01 Інструкція користувача  
482.ЧДТУ. 62289-01    90 01 Апробація  
кваліфікаційної роботи 
бакалавра 
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
75 
ДОДАТОК Б 
 
 
 
 
 
 
 
 
 
 
 
 
 
МОДУЛЬ КОНТРОЛЮ ДОСТУПУ ТА БАЗОВОЇ БЕЗПЕКИ В HR-СИСТЕМІ 
ВІЙСЬКОВОГО ОБЛІКУ 
 
 
 
 
Текст програми 
482.ЧДТУ. 62289-01 12 01 
 
Листів 5 
 
 
 
 
 
 
Розробник    _____________             Дмитро КЄРНУС 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси – 2026  
76 
Файл SecurityConfig.java 
package ua.edu.chdtu.hr.config; 
import lombok.RequiredArgsConstructor; 
import org.springframework.context.annotation.Bean; 
import org.springframework.context.annotation.Configuration; 
import org.springframework.security.authentication.AuthenticationProvider; 
import 
org.springframework.security.config.annotation.method.configuration.EnableMethodSecu
rity; 
import org.springframework.security.config.annotation.web.builders.HttpSecurity; 
import 
org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; 
import org.springframework.security.config.http.SessionCreationPolicy; 
import org.springframework.security.web.SecurityFilterChain; 
import 
org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter; 
import org.springframework.web.cors.CorsConfigurationSource; 
@Configuration 
@EnableWebSecurity 
@EnableMethodSecurity 
@RequiredArgsConstructor 
public class SecurityConfig { 
    private final JwtAuthenticationFilter jwtAuthFilter; 
    private final AuthenticationProvider authenticationProvider; 
    private final CorsConfigurationSource corsConfigurationSource; 
    @Bean 
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws 
Exception { 
        http 
            .cors(cors -> cors.configurationSource(corsConfigurationSource)) 
77 
            .csrf(csrf -> csrf.disable()) 
            .authorizeHttpRequests(auth -> auth 
                .requestMatchers("/api/v1/auth/**").permitAll() 
                .requestMatchers("/v3/api-docs/**", "/swagger-ui/**", "/swagger-
ui.html").permitAll() 
                .requestMatchers("/actuator/**").hasRole("ADMIN") 
                .anyRequest().authenticated() 
            ) 
            .sessionManagement(session -> session 
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS) 
            ) 
            .authenticationProvider(authenticationProvider) 
            .addFilterBefore(jwtAuthFilter, 
UsernamePasswordAuthenticationFilter.class); 
        return http.build(); 
    } 
} 
Файл JwtAuthenticationFilter.java 
package ua.edu.chdtu.hr.config; 
import jakarta.servlet.FilterChain; 
import jakarta.servlet.ServletException; 
import jakarta.servlet.http.HttpServletRequest; 
import jakarta.servlet.http.HttpServletResponse; 
import lombok.RequiredArgsConstructor; 
import org.springframework.lang.NonNull; 
import 
org.springframework.security.authentication.UsernamePasswordAuthenticationToken; 
import org.springframework.security.core.context.SecurityContextHolder; 
import org.springframework.security.core.userdetails.UserDetails; 
import org.springframework.security.core.userdetails.UserDetailsService; 
78 
import 
org.springframework.security.web.authentication.WebAuthenticationDetailsSource; 
import org.springframework.stereotype.Component; 
import org.springframework.web.filter.OncePerRequestFilter; 
import java.io.IOException; 
@Component 
@RequiredArgsConstructor 
public class JwtAuthenticationFilter extends OncePerRequestFilter { 
    private final JwtService jwtService; 
    private final UserDetailsService userDetailsService; 
    @Override 
    protected void doFilterInternal( 
            @NonNull HttpServletRequest request, 
            @NonNull HttpServletResponse response, 
            @NonNull FilterChain filterChain 
    ) throws ServletException, IOException { 
        final String authHeader = request.getHeader("Authorization"); 
        final String jwt; 
        final String userEmail; 
        if (authHeader == null || !authHeader.startsWith("Bearer ")) { 
            filterChain.doFilter(request, response); 
            return; 
        } 
        jwt = authHeader.substring(7); 
        userEmail = jwtService.extractUsername(jwt); 
        if (userEmail != null && 
SecurityContextHolder.getContext().getAuthentication() == null) { 
            UserDetails userDetails = 
this.userDetailsService.loadUserByUsername(userEmail); 
            if (jwtService.isTokenValid(jwt, userDetails)) { 
79 
                UsernamePasswordAuthenticationToken authToken = new 
UsernamePasswordAuthenticationToken( 
                        userDetails, 
                        null, 
                        userDetails.getAuthorities() 
                ); 
                authToken.setDetails( 
                        new WebAuthenticationDetailsSource().buildDetails(request) 
                ); 
                SecurityContextHolder.getContext().setAuthentication(authToken); 
            } 
        } 
        filterChain.doFilter(request, response); 
    } 
} 
80 
ДОДАТОК В 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
МОДУЛЬ КОНТРОЛЮ ДОСТУПУ ТА БАЗОВОЇ БЕЗПЕКИ В HR-СИСТЕМІ 
ВІЙСЬКОВОГО ОБЛІКУ 
 
 
 
 
 
 
 
 
 
 
ІНСТРУКЦІЯ КОРИСТУВАЧА 
482. ЧДТУ. 62289-01 34 01 
 
Листів 3 
 
 
 
 
 
Розробник    _____________  Дмитро КЄРНУС 
 
 
 
 
 
 
 
Черкаси – 2026  
81 
Доступ до HR-системи військового обліку є закритим і вимагає обов'язкової 
автентифікації користувача. Після запуску клієнтського застосунку відображається 
екран входу в систему (рис. В.1). 
 
Рисунок В.1 – Екран входу в систему 
Для успішної авторизації користувачу необхідно ввести своє ім'я користувача 
(логін) та пароль, після чого натиснути кнопку «Увійти». У разі успішної перевірки 
облікових даних сервер поверне JWT-токен, і користувача буде перенаправлено на 
головний екран системи (рис. В.2). 
 
Рисунок В.2 – Головний екран системи 
82 
Будь-які спроби звернутися до захищених ресурсів API без чинного токена або 
з правами, яких недостатньо для конкретної операції, будуть відхилені. Система 
поверне статус 401 Unauthorized або 403 Forbidden (рис. В.3). 
 
Рисунок В.3 – Обробка запиту без прав доступу (403 Forbidden) 
Всі критичні операції, такі як вхід у систему або генерація документів, 
записуються до модуля аудиту подій. Адміністратор або уповноважена особа має 
змогу переглядати цей журнал безпосередньо в базі даних (рис. В.4). 
 
Рисунок В.4 – Журнал аудиту подій безпеки 
  
83 
ДОДАТОК Г 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
МОДУЛЬ КОНТРОЛЮ ДОСТУПУ ТА БАЗОВОЇ БЕЗПЕКИ В HR-СИСТЕМІ 
ВІЙСЬКОВОГО ОБЛІКУ 
 
 
 
 
Апробація результатів кваліфікаційної роботи бакалавра 
482. ЧДТУ. 62289-01 90 01 
 
Листів 4 
 
 
 
 
 
 
 
 
 
 
Розробник    _____________  Дмитро КЄРНУС 
 
 
 
 
 
 
 
 
 
Черкаси – 2026 
84 
 
85 
Основні положення і результати кваліфікаційної роботи бакалавра доповідалися і 
були обговорені на конференції «День студентської науки кафедри КНСА», 22 квітня 
2026 року, Черкаси, Україна. 
Командний проєкт (Благовісний Юрій Олександрович, Голуб Данило 
Русланович, Дубровний Володимир Володимирович, Кєрнус Дмитро Олександрович) 
«Інформаційна автоматизована HR-система закладу вищої освіти» в День 
студентської науки кафедри КНСА посів 1 призове місце. 
 
86
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
