Підсистема журналювання подій аудиту
Загальний опис
Підсистема, призначенням якої є отримання та обробка повідомлень про виникнення значущих подій в системі з їх послідуючою гарантованою фіксацією в журналі аудиту для довготривалого зберігання та аналізу.
Функції підсистеми
-
Фіксація подій операцій над даними реєстру, ініційованих користувачем в рамках виконання бізнес-процесу
-
Фіксація подій, важливих для забезпечення захисту системи
-
Фіксація загальних подій рівня системи
Технічний дизайн підсистеми
На даній діаграмі зображено компоненти, які входять в Підсистему журналювання подій аудиту та їх взаємодію з іншими підсистемами в рамках реалізації функціональних сценаріїв.
Підсистема журналювання подій аудиту надає асинхронний API у вигляді Kafka-топіка audit-events для публікації повідомлень про події аудиту цільовими підсистемами згідно визначеної схеми та використовує для зберігання даних в Операційну БД подій аудиту механізм, який базується на Kafka Connect API для забезпечення exactly once семантики обробки повідомлень.
Функції перегляду журналу аудиту доступні адміністраторам через веб-інтерфейс Підсистеми аналітичної звітності у вигляді набору службових дашбордів, які створюються під час розгортання реєстру Підсистемою розгортання та налаштування Платформи та реєстрів.
|
Детальніше з дизайном Підсистеми аналітичної звітності можна ознайомитись у відповідному розділі. |
Складові підсистеми
| Назва компоненти | Представлення в реєстрі | Походження | Репозиторій | Призначення |
|---|---|---|---|---|
Сервіс збереження схем повідомлень подій аудиту |
|
3rd-party |
gerrit:/mdtu-ddm/data-architecture/devops-application/kafka-schema-registry |
Перевірка відповідності структури повідомлення поточній схемі |
Сервіс збереження подій аудиту |
|
3rd-party |
gerrit:/mdtu-ddm/data-architecture/devops-application/strimzi-kafka-operator |
Збереження повідомлень в базу даних |
|
origin |
github:/epam/edp-ddm-registry-postgres/tree/main/platform-db/changesets/audit |
Відокремлена БД для збереження аудиту подій |
Перелік сервісів, які підлягають аудиту
| Підсистема власник | Назва компоненти | Представлення в реєстрі |
|---|---|---|
Сервіс синхронного управління даними реєстру |
registry-rest-api |
|
Сервіс асинхронного управління даними реєстру |
registry-kafka-api |
|
Сервіс доступу до історичних даних БП |
process-history-service-api |
|
Сервіс фіксації історичних подій БП |
process-history-service-persistence |
|
Сервіс управління налаштуваннями користувачів |
user-settings |
|
Сервіс нотифікацій користувачів |
ddm-notification-service |
Атрибути якості підсистеми
|
Секція потребує допрацювання… |
Security
Використання автентифікації за допомогою TLS для підключення до брокера повідомлень з боку додатка, унеможливлює здійснення атак типу людина посередині (Man in the middle).
Всі дані в русі також шифруються за допомогою TLS.
Reliability
Загальна надійність системи забезпечується переліком механізмів реалізованих в компонентах які використовуються підсистемою.
-
Kafka (
Replication,Fault Tolerance,Message Persistence,Message immutabiliuty,Acknowledgment Mechanism) -
Crunchy PostgreSQL (
Replication and Failover,High Availability)
Scalability
Можливість паралельної обробки повідомлень та відсутність зберігання стану в додатку забезпечує горизонтальне масштабування.
Performance
Події сервісу створюються як асинхронні події (Applicaton Events) і таким чином не вносять значний вплив на швидкодію сценаріїв в середині сервісів.