Підсистема управління даними реєстру
| 🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію. |
1. Загальний опис
Підсистема, призначення якої є надання доступу до даних реєстру через REST API та Підсистему асинхронного обміну повідомленнями, з можливістю запису, читання, зміни та видалення даних. Також підсистема відповідальна за управління збереженими файлами, перевіркою цілісності даних та виявленням несанкціонованих змін.
2. Функції підсистеми
-
Створення, читання, зміна та видалення записів реєстру.
-
Пошук даних за параметрами.
-
Реалізація рольового доступу до даних (
RBAC). -
Ведення історичності змін.
-
Збереження інформації про походження даних.
-
Збереження пов’язаних файлів реєстру.
-
Збереження підписаних запитів в якості підстав для зміни даних реєстру.
3. Технічний дизайн підсистеми
3.1. Аудит та журналювання подій
Події маніпуляцій з даними реєстру фіксуються у журналі аудиту з повним контекстом.
Тип події |
Спосіб фіксації |
Службова назва |
Опис |
USER_ACTION |
До та після події |
SEARCH ENTITY |
Надходження запиту про пошук даних до Сервіс синхронного управління даними реєстру |
USER_ACTION |
До та після події |
SEARCH |
Надходження запиту про пошук даних до Сервіс синхронного управління даними реєстру |
USER_ACTION |
До та після події |
READ ENTITY |
Надходження запиту про отримання даних за ідентифікатором до Сервіс синхронного управління даними реєстру |
USER_ACTION |
До та після події |
UPDATE ENTITY |
Надходження запиту про внесення змін до Сервіс синхронного управління даними реєстру |
USER_ACTION |
До та після події |
UPSERT ENTITY |
Надходження запиту про внесення створення або зміну сутності до Сервіс синхронного управління даними реєстру |
USER_ACTION |
До та після події |
DELETE ENTITY |
Надходження запиту про видалення запису до Сервіс синхронного управління даними реєстру |
USER_ACTION |
До та після події |
SELECT FROM TABLE |
Операція пошуку даних в БД |
USER_ACTION |
До та після події |
KAFKA_REQUEST_UPDATE |
Надходження запиту про внесення змін до Сервіс асинхронного управління даними реєстру |
USER_ACTION |
До та після події |
KAFKA REQUEST CREATE |
Надходження запиту про створення нового запису до Сервіс асинхронного управління даними реєстру |
USER_ACTION |
До та після події |
KAFKA REQUEST DELETE |
Надходження запиту про видалення запису до Сервіс асинхронного управління даними реєстру |
USER_ACTION |
До та після події |
UPDATE TABLE |
Операція внесення змін в БД |
USER_ACTION |
До та після події |
DELETE FROM TABLE |
Операція видалення запису з БД |
USER_ACTION |
До та після події |
INSERT INTO TABLE |
Операція створення нового запису до БД |
USER_ACTION |
Під час виникнення |
CONSTRAINT ERROR |
Збереження або зміна даних порушують наявні обмеження БД |
USER_ACTION |
Під час виникнення |
CLIENT ERROR |
Клієнтська помилка при синхронному запиті |
USER_ACTION |
Під час виникнення |
RUNTIME ERROR |
Помилка в процесі опрацювання запита |
USER_ACTION |
Під час виникнення |
INVALID_HEADER_VALUE |
Недопустиме значення заголовків синхронного запиту |
USER_ACTION |
Під час виникнення |
HEADERS_ARE_MISSING |
Один або декілько обов’язкових заголовків відсутні |
USER_ACTION |
Під час виникнення |
LIST_SIZE_VALIDATION_ERROR |
Кількість елементів для завантаження перевищено |
USER_ACTION |
Під час виникнення |
VALIDATION_ERROR |
Помилка вхідних даних при синхронному запиті |
USER_ACTION |
Під час виникнення |
PROCEDURE_ERROR |
Помилка виклику процедури |
USER_ACTION |
Під час виникнення |
THIRD_PARTY_SERVICE_UNAVAILABLE |
При опрацюванні запитів одна з систем Платформи не була доступна |
USER_ACTION |
Під час виникнення |
NOT_FOUND |
При пошуку сутності по ідентифікатору, сутність не було знайдено. |
|
Детальніше з дизайном Підсистеми журналювання подій аудиту можна ознайомитися за посиланням. |
4. Складові підсистеми
| Назва компоненти | Представлення в реєстрі | Походження | Репозиторій | Призначення |
|---|---|---|---|---|
Сервіс синхронного управління даними реєстру |
|
origin |
github:/epam/edp-ddm-service-generation-utility |
Обробляє синхронні REST API запити на читання та запис даних реєстру. |
Сервіс асинхронного управління даними реєстру |
|
origin |
Обробляє асинхронні запити на читання та запис даних реєстру. |
|
|
origin |
База даних що містить службові таблиці сервісів і всі таблиці реєстру змодельовані адміністратором регламенту. Вона також фіксує історію змін даних та перевіряє права згідно з RBAC. |
||
|
origin |
- |
Зберігання цифрових документів реєстру |
|
|
origin |
- |
Зберігання підписаних даних при внесенні в реєстр |
|
|
origin |
- |
Тимчасове зберігання даних для передачі в рамках міжсервісної взаємодії всередині підсистеми |
5. Технологічний стек
При проектуванні та розробці підсистеми, були використані наступні технології:
6. Атрибути якості підсистеми
6.1. Scalability
Підсистема управління даними реєстру підтримує як горизонтальне, так і вертикальне масштабування.
|
Детальніше з масштабуванням підсистем можна ознайомитись у відповідних розділах: |
6.2. Observability
Підсистема управління даними реєстру підтримує журналювання та збір метрик продуктивності для подальшого аналізу через веб-інтерфейси відповідних підсистем Платформи.
|
Детальніше з дизайном підсистем можна ознайомитись у відповідних розділах: |
6.3. Auditability
Підсистема управління даними реєстру фіксує значимі технічні та бізнес події, пов’язані з експлуатацією системи кінцевими користувачами використовуючи підсистему журналювання подій аудиту.
6.4. Security
Автентифікація запитів відбувається на рівні KeyCloak підсистемою управління користувачами та ролями.
Механізм авторизації включає в себе розмежування прав доступу до даних на основі ролей (RBAC).
За втілення підходу найменший привілеїв відповідає адміністратор реєстру який повинен налаштувати таблиця ролей відповідним чином після створення регламенту реєстру. Процес зміни прав доступу описаний у статі.
Задля забезпечення стійкості системи та запобігання зловживанню сервісами підсистема надає механізм керування рейт лімітами для публічного REST API. Встановлення рейт лімітів може обмежити зловмисне або неправомірне використання сервісів, наприклад, запобігаючи автоматизованому збору даних (web scraping) або спаму, брутфорс, сканування на вразливості, зменшення навантаження та DDoS.
Підсистема являється учасником Service Mesh та відповідно усі мережеві взаємодії контролюються Підсистемою управління міжсервісною взаємодією. На іншому рівні мережеве спілкування з підсистемою також контролюється мережевими політиками Openshift.
Дані під час внутрішньої комунікації на рівні платформи а також з зовнішніми системами через REST API захищені надійним шифруванням каналу звязку яке використовує надійний протокол TLS 1.2. Підсистема не зберігає дані а лише оброблює їх відповідно шифрування при зберігання не використовується.
Компоненти підсистеми підлягають моніторингу та логуванню згідно вимог безпеки.
Підсистема журналювання подій аудиту зберігає події доступу до та модифікації даних. Події аудиту місять інформацію про користувача, який ініціював подію, або про систему, з якої було здійснено запит. Події аудиту забезпечують достатній рівень деталізації з яких можна зрозуміти що відбувалося в системі включно з результатами виконання запитів або відповіді від систем.
Для забезпечення характеристики невід’ємності події аудиту логують результат виконання дії з повним контекстом тож існує достатньо доказів того, що певна подія відбулася, і заперечити це неможливо.
|
Детальніше з принципами безпечного дизайну можна ознайомитись у відповідних розділах: |