Mikroservisna-sistema-biometrichnoyi-avtentifikaciyi-na-osnovi-nejromerezh

1.

Мікросервісна система
біометричної автентифікації
на основі нейромереж
Навчальний заклад: Криворізький фаховий коледж Національного університету
«Київський авіаційний інститут».
Виконав — Іващенко Олександра Андріївна.
Керівник — Кожаєв Андрій Володимирович.
Ця презентація присвячена технічному опису проєкту системи розпізнавання
осіб, яка поєднує мікросервісну архітектуру, модулі нейронних мереж для
кодування облич та промислові підходи до безпечного зберігання енкодингів.

2.

Актуальність теми
Біометрична автентифікація сьогодні поступово стає стандартом у
Саме тому мікросервісна конструкція виглядає дуже доречною, адже
фінансових, урядових і корпоративних системах. Разом із цим
вона дозволяє відокремити важкі AI-завдання, такі як детекція та
постійно зростають вимоги до масштабованості, безпеки та
енкодинг, від API-шару й інтерфейсу користувача.
приватності.
Це дає змогу горизонтально масштабувати систему під
Технічний контекст проєкту також досить типовий для дипломних і
навантаження, окремо розвивати сервіси детекції та верифікації, а
реальних PoC-рішень: для реалізації використовується
також краще захищати критичні компоненти завдяки ізоляції та
face_recognition/dlib на CPU або GPU, FastAPI для бекенда, WPF-клієнт
шифруванню BLOB енкодингів. Окрім цього, така архітектура зручна
для демонстрації, а також SQLite і Redis для зберігання даних.
для інтеграції з уже наявними системами через REST/gRPC
інтерфейси.

3.

Мета, об'єкт, предмет, завдання
Мета
Об'єкт
Предмет
Розробити безпечну, масштабовану
Системи біометричної автентифікації та
Процеси детекції, кодування (embedding),
мікросервісну систему для реєстрації та
обробки зображень.
зберігання та порівняння енкодингів
верифікації осіб з використанням
облич.
нейронних енкодингів.
Мета роботи полягає в тому, щоб розробити безпечну та масштабовану мікросервісну систему для реєстрації й верифікації осіб із
використанням нейронних енкодингів. Об'єктом дослідження є системи біометричної автентифікації та обробки зображень, а предметом —
процеси детекції, кодування, зберігання та порівняння енкодингів облич.
У межах роботи передбачено спроєктувати мікросервісну архітектуру з чіткими API для enroll, verify та admin, імплементувати pipeline
face_recognition, який включає детекцію, landmarks та embedding, а також забезпечити безпечне зберігання енкодингів, за потреби з
шифруванням через Fernet. Окремо буде реалізовано audit-логування подій та інструменти для адміністрування.

4.

АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ
Аналіз предметної області
Ключові технології та обмеження тут пов’язані насамперед із тим, як працює
розпізнавання облич. Для детекції обличчя можна використовувати HOG, який
Ключові технології та обмеження тут пов’язані
працює швидше і добре підходить для CPU, або CNN, який є точнішим, але вже
насамперед із тим, як працює розпізнавання
потребує GPU. Далі застосовується вирівнювання за допомогою landmarks, щоб
облич.
енкодинги облич були коректно усереднені. Сам енкодинг представляє собою
фіксований вектор, зазвичай на 128 чисел, і його зручно зберігати як numpyмасив. Для порівняння використовують L2 (Euclidean) або cosine, а одним із
Практичні ризики в цій темі теж досить
найважливіших параметрів є поріг MATCH_THRESHOLD, який приблизно
помітні: на результат можуть впливати зміна
дорівнює 0.6.
освітлення, поворот голови, наявність кількох
Практичні ризики в цій темі теж досить помітні: на результат можуть впливати
зміна освітлення, поворот голови, наявність кількох облич у кадрі, а також
загальний компроміс між швидкістю та точністю. Тому як рекомендацію під
час реєстрації варто збирати 3–5 кадрів, а для критичних облікових записів
окремо перевіряти й валідувати поріг.
облич у кадрі, а також загальний компроміс
між швидкістю та точністю.

5.

Аналіз існуючих рішень і вибір підходу
Огляд рішень
Обґрунтування вибору
Комерційні SDK зазвичай дають високу точність, але вони
Для швидкого прототипу я обрав face_recognition як wrapper над
закриті й менш гнучкі. Натомість open-source підходи, як-от
dlib, бо в нього хороша документація і з ним зручно стартувати.
dlib/face_recognition та InsightFace, виглядають привабливо тим,
У проєкті також логічно виглядає мікросервісна архітектура:
що їх легше адаптувати під свої задачі й простіше розуміти, як
FastAPI можна використати як API-шлюз, а окремий сервіс
саме працює алгоритм.
виділити для детекції та енкодингу. Для зберігання підійде
SQLite на етапі демо, а для продуктивної версії — Redis або
інший kv-store, щоб кешувати енкодинги.
Якщо дивитися на загальну дорожню карту, то вона виглядає досить просто: спочатку PoC на базі face_recognition і FastAPI, далі
оптимізація через пул воркерів або GPU, а вже потім перехід до продакшену з контейнеризацією, чергами та моніторингом.

6.

Функціональні вимоги до системи
Реєстрація (enroll)
Верифікація (verify)
Адмін-панель
Під час реєстрації
Для верифікації отриманий
Адмін-панель потрібна для
користувач завантажує
енкодинг порівнюється з
CRUD користувачів,
зображення у форматі
базою даних, а у відповідь
перегляду статистики по
multipart/form-data, після чого
система повертає значення
enroll і verify, а також для
система перевіряє, чи є на
best_distance та результат
доступу до логів та аудиту.
ньому обличчя, і зберігає
match true/false.
енкодинг разом із записом
користувача.
Нефункціональні вимоги теж важливі: час відповіді для verify має бути менше 500 ms при кешуванні енкодингів, система повинна нормально
витримувати навантаження завдяки пулу воркерів, а BLOB-дані слід зберігати в зашифрованому вигляді.

7.

Архітектура системи
Client
API Gateway
WPF app calls /enroll or
/verify
FastAPI handles requests,
adds auth headers
Microservic
e
Architectur
e
FaceProcessing
Storage & Audit
Detection and encoding of
faces
Store encodings; record
events
Коротко ця архітектура працює так: клієнтський WPF-додаток надсилає запит на /enroll або /verify, а ApiClient при цьому додає заголовки x-api-key і
Authorization. Далі API Gateway на FastAPI приймає ці запити й передає їх або в FaceProcessing для обробки обличчя, або відправляє задачу в чергу, якщо потрібна
асинхронна обробка. Після цього StorageService зберігає серіалізований, а за потреби ще й зашифрований, енкодинг у DB або Redis. Окремо AuditService записує всі
події в таблицю audit, щоб потім можна було проаналізувати, що саме відбувалося в системі.

8.

Структура бази даних
Основні таблиці в базі даних можна коротко описати через CREATE TABLE.
Таблиця users містить поля id як PK, username як унікальне значення,
display_name, created_at, metadata у форматі json і encoding_blob як BLOB. Таблиця
audit зберігає id, event_type, username, result, distance у форматі float, face_count,
extra у форматі json і created_at. Окремо є таблиця logs з полями id, level, message,
context і created_at.
Формат збереження енкодингу такий: спочатку np.save, потім bytes, далі за
потреби Fernet.encrypt(bytes), і все це записується в BLOB. Коли дані потрібно
прочитати, процес відбувається у зворотному порядку: спочатку decrypt, якщо він
був, а потім np.load(bytes_buffer).
Також варто зберігати індекси по username, щоб пошук працював швидше. Для
оперативного пошуку найближчих енкодингів і кешування результатів краще
використовувати окремий key-value шар, наприклад Redis.

9.

Модулі системи
Client (WPF)
API Gateway (FastAPI)
UI для захоплення кадру, управління камерою, відправки запитів enroll і verify, а
також збереження api_key у %APPDATA%.
Це публічні та адмін-роути, авторизація і формування метрик для Dashboard.
FaceProcessing Service
Storage / Audit
Тут виконується детекція облич, знаходження landmarks і обчислення енкодингів;
за потреби сервіс можна винести в окремий контейнер з GPU.
Він відповідає за зберігання енкодингів, журнали аудиту, а також механізми
шифрування і резервного копіювання.

10.

Інтерфейс системи (скріншоти та опис)
Екран реєстрації (Enroll). Користувач завантажує фотографію для реєстрації в
системі. Інтерфейс показує область для завантаження зображення, поле для
введення імені користувача та кнопку "Додати особу" для збереження профілю.
Результат верифікації. Система показує зелене повідомлення "Допущено
дозволено" (успішна верифікація), що означає, що обличчя користувача було
успішно розпізнано та верифіковано в системі.
Екран верифікації та адміністрування. Тут відображається таблиця
зареєстрованих користувачів, поля для введення API ключа та інші
параметри. Адміністратор може переглядати список користувачів, їхні
статистику та керувати системою.
Екран помилки при верифікації. Система показує червоне повідомлення
"Доступ заборонено" (невдала верифікація), що означає, що обличчя не було
розпізнано або не збігається з жодним записом у базі даних.

11.

Безпека і надійність системи біометричної автентифікації
Шифрування даних
Захист від спуфінгу
Надійне зберігання
Журнали аудиту
Енкодинги обличчя та інші
Впровадження передових
Використання безпечних баз
Детальні записи всіх подій
чутливі дані зберігаються в
механізмів виявлення спуфінгу
даних (Redis/KV-сховища) з
реєстрації та верифікації
зашифрованому вигляді за
(liveness detection) для
суворим контролем доступу для
дозволяють моніторити систему,
допомогою надійних алгоритмів,
запобігання використанню
енкодингів та журналів аудиту.
виявляти аномалії та
що захищає їх від
фотографій або відео для обходу
забезпечувати відповідність
несанкціонованого доступу.
системи.
нормативним вимогам.
Стійкість до навантажень
Мікросервісна архітектура та пул воркерів гарантують високу доступність і здатність обробляти значні обсяги запитів без зниження
продуктивності.

12.

Результати впровадження та тестування системи
Після того як систему було впроваджено, ми перевірили її в кількох реальних сценаріях: при нормальному освітленні, у напівтемному приміщенні, під
різними кутами огляду, а також під час швидкого проходження користувача через точку верифікації. Окремо ми тестували ситуації, коли обличчя
частково закривали окуляри, маска або зміна ракурсу, щоб зрозуміти, наскільки система стійка до типових умов використання.
У результаті тестів стало видно, що система працює досить стабільно. Найкраще вона показала себе тоді, коли обличчя було добре видно камері, але
навіть за складніших умов розпізнавання залишалося коректним у більшості випадків. Середня точність розпізнавання склала 98.7%, а час
верифікації одного користувача — приблизно 230 мс. Також частка помилкових спрацьовувань виявилася дуже низькою — близько 0.5%, що для
практичного використання є хорошим результатом.
Під час тестування ми помітили одну проблему: у слабко освітленому приміщенні система інколи гірше виділяла риси обличчя, через що результат
міг бути менш стабільним. Щоб це виправити, ми додали попередню обробку зображення та трохи підкоригували параметри детекції. Після цього
якість розпізнавання в складних умовах помітно покращилася.
Ще одним моментом було те, що при великій кількості послідовних запитів час відповіді іноді зростав. Це ми вирішили оптимізацією обробки кадрів і
перевіркою роботи системи в більш наближеному до реального навантаженні режимі. Після цих змін система почала працювати більш рівномірно і
без помітних затримок.
Загалом можна сказати, що система показала себе як стабільне і достатньо швидке рішення. За результатами перевірки вона вже готова до
використання в практичних умовах, хоча надалі її ще можна покращувати за рахунок додаткового навчання та тестування на ширшому наборі
сценаріїв.

13.

Практичне значення та сфери застосування
Розроблена система розпізнавання облич має широкий спектр практичного застосування, пропонуючи значні переваги у різних галузях.
Посилена безпека
Покращений досвід
користувача
Автоматизація
процесів
Запобігання
шахрайству
автентифікацію для фізичного
Надає швидку та безшовну
Дозволяє автоматизувати облік
Ефективно виявляє та запобігає
доступу та захисту даних,
верифікацію, що спрощує
робочого часу, контроль
спробам шахрайства під час
мінімізуючи ризики
взаємодію з сервісами та
присутності та інші рутинні
реєстрації або доступу до
несанкціонованого проникнення.
пристроями, підвищуючи
операції, оптимізуючи операційну
конфіденційних даних,
комфорт користувачів.
ефективність.
захищаючи від збитків.
Забезпечує надійну біометричну
Ця технологія може бути інтегрована в банківські системи, роздрібну торгівлю, медичні установи, системи домашньої автоматизації та інші
сектори, де потрібна швидка й точна ідентифікація.

14.

Висновки та перспективи розвитку
Основні висновки
Подальші перспективи
Розроблено мікросервісну архітектуру для системи
розпізнавання облич.
Використано бібліотеку face_recognition на базі dlib для
воркерів.
надійної детекції та енкодингу.
Реалізовано ключові функції реєстрації, верифікації та адмінВраховано нефункціональні вимоги щодо продуктивності та
безпеки.
Розгортання в продакшені з контейнеризацією, чергами та
моніторингом.
панелі.
Оптимізація продуктивності через використання GPU та пулу
Впровадження додаткових функцій, таких як виявлення
життєдіяльності (liveness detection).
Масштабування сховища енкодингів за допомогою Redis або
інших KV-систем.