Підсистема журналювання подій аудиту

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Загальний опис

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

2. Функції підсистеми

  • Фіксація подій операцій над даними реєстру, ініційованих користувачем в рамках виконання бізнес-процесу

  • Фіксація подій, важливих для забезпечення захисту системи

  • Фіксація загальних подій рівня системи

3. Технічний дизайн підсистеми

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

audit overview

Підсистема журналювання подій аудиту надає асинхронний API у вигляді Kafka-топіка audit-events для публікації повідомлень про події аудиту цільовими підсистемами згідно з визначеною схемою та використовує для зберігання даних в Операційну БД подій аудиту механізм, який базується на Kafka Connect API для забезпечення exactly once семантики обробки повідомлень.

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

Детальніше з дизайном Підсистеми аналітичної звітності можна ознайомитись у відповідному розділі.

4. Складові підсистеми

Назва компоненти Представлення в реєстрі Походження Репозиторій Призначення

Сервіс збереження схем повідомлень подій аудиту

kafka-schema-registry

3rd-party

github:/epam/edp-ddm-kafka-schema-registry

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

Сервіс збереження подій аудиту

kafka-connect-cluster-connect

3rd-party

github:/epam/edp-ddm-strimzi-kafka-operator

Збереження повідомлень в базу даних

Операційна БД подій аудиту

operational:audit

origin

github:/epam/edp-ddm-registry-postgres/tree/main/platform-db/changesets/audit

Відокремлена БД для збереження аудиту подій

5. Перелік сервісів, які підлягають аудиту

Підсистема власник Назва компоненти Представлення в реєстрі

Підсистема управління даними реєстру

Сервіс синхронного управління даними реєстру

registry-rest-api

Сервіс асинхронного управління даними реєстру

registry-kafka-api

Підсистема виконання бізнес-процесів

Сервіс фіксації історичних подій БП

process-history-service-persistence

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

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

user-settings

Підсистема нотифікацій користувачів

Сервіс нотифікацій користувачів

ddm-notification-service

Підсистема формування витягів реєстру

Сервіс управління витягами

excerpt-service-api

Сервіси генерації витягів

excerpt-worker

excerpt-worker-csv

excerpt-worker-docx

Підсистема моделювання регламенту реєстру

Утиліта завантаження надавачів послуг

publish-users-job

Підсистема зовнішніх інтеграцій

API-шлюз для читання даних реєстру зовнішніми системами

registry-soap-api-deployment

Сервіс синхронного управління даними реєстру для публічного доступу до даних

registry-rest-api-public

Сервіс синхронного управління даними реєстру для міжреєстрової взаємодії

registry-rest-api-ext

6. Технологічний стек

При проєктуванні та розробці підсистеми, були використані наступні технології:

7. Атрибути якості підсистеми

7.1. Security

Використання автентифікації за допомогою TLS для підключення до брокера повідомлень з боку додатка, унеможливлює здійснення атак типу людина посередині (Man in the middle). Всі дані в русі також шифруються за допомогою TLS.

7.2. Reliability

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

  • Kafka (Replication, Fault Tolerance, Message Persistence, Message immutability, Acknowledgment Mechanism)

  • Crunchy PostgreSQL (Replication and Failover, High Availability)

7.3. Scalability

Можливість паралельної обробки повідомлень та відсутність зберігання стану в додатку забезпечує горизонтальне масштабування.

7.4. Performance

Події сервісу створюються як асинхронні події (Application Events) і таким чином не вносять значний вплив на швидкодію сценаріїв в середині сервісів.

7.5. Data Integrity

Цілісність та незмінність даних гарантована незмінністю повідомлень Kafka та обмеженням доступу на операції запису до БД.

7.6. Data Retention and Archiving

Політики збереження та архівування реалізовано за допомогою налаштувань вбудованих механізмів збереження даних повідомлень Kafka та бекапування БД.