Аудит взаємодій в мережі
(Розділ: Екосистема та Мережа)
1) Навіщо це потрібно
Аудит взаємодій забезпечує доказовість фактів: хто з ким обмінявся чим, коли і в якому стані. Це знижує вартість розглядів, прискорює комплаєнс-перевірки, підвищує довіру між учасниками і дозволяє масштабувати мережу без «ручного арбітражу».
2) Область охоплення і межі
Канали: синхронні RPC (REST/gRPC), вебхуки, події в шині, батчі/файли.
Артефакти: запити/відповіді, події та квитанції (receipts), підписи, хеші корисних навантажень, журнали змін.
Об'єкти аудиту: бізнес-операції (платіж, ігровий раунд, KYC-вердикт), технічні дії (ретраї, таймаути, редрав).
Межі: per-тенант, per-регіон, per-інтеграція; агрегування на глобальному рівні.
3) Принципи аудиту
1. Типове підтвердження: критичні повідомлення супроводжуються підписами і квитанціями.
2. Наскрізна кореляція: єдиний'trace _ id '/' span _ id'для RPC, подій, вебхуків і батчів.
3. Ідемпотентність і відтворюваність: можливість детермінованого повторного програвання.
4. Незалежна перевірка: артефакти можуть бути верифіковані без довіри до постачальника.
5. Приватність і мінімізація: докази замість зайвих PII; токенізація та редагування (redaction).
6. Автоматизація: перевірки і звірки виконуються регулярно і машинно.
4) Модель артефактів
Квитанція (Receipt): `{delivery_id, content_hash, occurred_at, producer, signature}`.
Журнал подій: append-only, записи с `event_id`, `trace_id`, `schema_version`, `region`, `tenant`.
Підписи: для вхідних/вихідних повідомлень (mTLS + підпис заголовків/тіла).
Merkle-коріння: періодичні «зрізи» журналу з публікацією кореня і ланцюжків включення.
Каталог схем: стабільні версії контрактів (expand → migrate → contract).
5) Наскрізне трасування
У кожному повідомленні: `trace_id`, `parent_span_id`, `idempotency_key`, `request_id`.
Прокидання контексту через: RPC → шину подій → вебхуки → батчі.
Для асинхронних процесів: 'correlation _ id'+ статус-ендпоінти (poll/push).
6) Підписи і анти-replay
Заголовки: `signature`, `timestamp`, `nonce`, `delivery-id`.
Вікно допустимості часу (TTL), захист від повторів, чорні списки використаних'nonce'.
Ротація ключів і pinning публічних ключів партнерів; зберігання ланцюжків довіри.
7) Прозорі журнали (immutability)
Append-only із захистом від перезапису; періодична публікація Merkle-кореня.
Перевірка включення/незмінності за «доказами шляху».
Розділення доменів: технічні логи (високий обсяг) і бізнес-журнали (квитанції).
8) Політики зберігання і приватність
Терміни зберігання: за рівнями критичності (наприклад, платежі - 7-10 років, телеметрія - 30-90 днів).
Локалізація: PII/фіндані - тільки в «зонах довіри» регіону; в журналах - хеші/токени.
Право на забуття: видаляється первинний PII-об'єкт; в журналі залишається доказовість (хеш/коммітмент).
Data minimization: події несуть ідентифікатори/докази, а не «зайві» атрибути.
9) Автоперевірки та звірки
Дуга доставки вебхуків: відправка → ретраї → підтвердження (2xx) → квитанція приймача.
Звірка консистентності: періодичні порівняння снапшотів (Merkle-дифф).
Алерти якості: зростання «протухлих»'nonce', розбіжності хешів, лагів реплікації, p95 часу верифікації підпису.
Regression-перевірки контрактів: валідність схем, зворотна сумісність.
10) Процедури розглядів (Dispute/Арбітраж)
Предмет спору: нестикування сум/статусів, затримка, подвійна доставка, недоступність.
Набір доказів: квитанції сторін, включення в журнал (Merkle-шлях), підпис, траса'trace _ id'.
Процес: реєстрація спору → автоматична перевірка артефактів → вердикт/компенсація (ескроу/штрафи SLA).
SLO арбітражу: цільове TTR (наприклад, ≤ 24-48 годин за критичними кейсами).
11) Метрики аудиту (SLO/SLI)
Покриття квитанціями критичних потоків (%) і частка підписаних повідомлень.
Час верифікації підпису/включення (p95/p99).
Успішність доставки вебхуків і середній лаг ретраїв.
Частка ідемпотентно оброблених дублів.
Кількість/частка інцидентів з повним набором артефактів (evidence completeness).
TTR по спорах, частка автоматичних вердиктів.
12) Дашборди
Контур доказовості: % підписів, валідність, ротації ключів.
Доставка та ретраї: теплові карти лагів, ретраї по інтеграціях/регіонах.
Іммутабельність: прогрес публікацій Merkle-коренів, успішність зовнішніх перевірок.
Спори: статистика причин, суми, TTR, результати.
13) Організація і ролі
Власник аудиту: відповідає за стандарти артефактів та їх доступність.
Вартовий ключів (KMS/HSM): ротації, політики доступу, журнал операцій.
Інтеграційний офіс: сертифікація контрактів/вебхуків, «маркетплейс» статусів.
Арбітраж/комплаєнс: незалежна перевірка, ведення реєстру спорів і вердиктів.
14) Процеси інцидентів
Плейбуки: втрата кореляції, недостовірний підпис, гальмівний приймач вебхуків, «шторм ретраїв».
Деградація за планом: зниження частоти, перемикання на батчі/відкладені операції, «паузери» маршрутів.
Постмортеми: обов'язкові action items, оцінка покриття артефактами.
15) Інструменти та інтеграції
Трасування: OpenTelemetry-сумісні агенти, експорт'trace _ id'в логи і події.
Валідація підписів: сервіси валідації на Edge/API-шлюзі, централізований каталог ключів.
Журнали: сховища з WORM-семантикою (write once, read many) і Merkle-снапшоти.
Контракти як код: генерація SDK/валідаторів схем, автотести зворотної сумісності.
16) Чек-лист впровадження
1. Описати критичні потоки і обов'язкові артефакти (квитанції, підписи, хеші).
2. Ввести наскрізний'trace _ id'і'idempotency _ key'у всі канали.
3. Реалізувати підписи і анти-replay для вебхуків; статус-ендпоінти.
4. Запустити append-only журнали і публікувати Merkle-коріння з заданою періодичністю.
5. Налаштувати автосверки снапшотів і алерти якості.
6. Визначити терміни зберігання, редакцію PII і локалізацію даних.
7. Впровадити сертифікацію інтеграцій та regression-перевірки контрактів.
8. Створити дашборди і SLO для аудиту; банку плейбуків інцидентів і суперечок.
9. Навчити команди: як формувати/перевіряти артефакти, як вести розгляди.
10. Проводити регулярні GameDays: «втрата кореляції», «шторм ретраїв», «компрометація ключа».
17) Ризики та анти-патерни
«Логи є, але доказів немає»: немає підпису/квитанції/хешу.
Склеювання трас втрачається на кордонах: відсутність'trace _ id'в подіях/вебхуках.
Зайвий PII в журналах: порушення приватності та регуляторні ризики.
Некеровані ключі: відсутність ротацій і pinning → атаки відтворення.
Відсутність автозвірок: розбіжності виявляються тільки «вручну» і пізно.
18) Специфіка для iGaming/фінтех
Ігрові результати: квитанції «provably fair» (коміт/підпис/ТЕЄ-атестація) + запис у прозорий журнал.
Платежі/виплати: двосторонні квитанції та звірка реєстрів (Merkle-дифф), SLA-штрафи як код.
Афіліати/вебхуки: HMAC + nonce, ідемпотентність прийому, статус-ендпоінти; звіти - як підписані снапшоти.
КУС/ризик: атестації/верифіковані креденшели; зберігати докази, а не вихідний PII.
19) FAQ
Чи потрібно підписувати все? Підписуйте критичні потоки і референсні артефакти; для телеметрії достатньо хешів і кореляції.
Де зберігати докази? У WORM-сумісних журналах з Merkle-зрізами; PII тримати в «зонах довіри».
Як знизити навантаження? Батчувати квитанції, зберігати хеші і посилання, а не повні payload'и.
Що первинно - логи чи квитанції? Квитанції: вони компактні і доказові; логи - для деталізації.
Резюме: Аудит взаємодій - це система доказовості, а не просто «логи». Стандартизуйте артефакти, забезпечте наскрізну кореляцію та іммутабельність журналів, автоматизуйте звірки та розгляди. Тоді мережа отримує перевірюваність, швидку реакцію на інциденти і передбачуваний комплаєнс при масштабуванні по учасниках і регіонах.