Аудит взаимодействий в сети

(Раздел: Экосистема и Сеть)

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» (коммит/подпись/TEE-аттестация) + запись в прозрачный журнал.
Платежи/выплаты: двусторонние квитанции и сверка реестров (Merkle-дифф), SLA-штрафы как код.
Аффилиаты/вебхуки: HMAC+nonce, идемпотентность приема, статус-эндпоинты; отчеты — как подписанные снапшоты.
KYC/риск: аттестации/верифицируемые креденшелы; хранить доказательства, а не исходный PII.

19) FAQ

Нужно ли подписывать все? Подписывайте критичные потоки и референсные артефакты; для телеметрии достаточно хэшей и корреляции.
Где хранить доказательства? В WORM-совместимых журналах с Merkle-срезами; PII держать в «зонах доверия».
Как снизить нагрузку? Батчировать квитанции, хранить хэши и ссылки, а не полные payload’ы.
Что первично — логи или квитанции? Квитанции: они компактны и доказуемы; логи — для детализации.

Резюме: Аудит взаимодействий — это система доказуемости, а не просто «логи». Стандартизируйте артефакты, обеспечьте сквозную корреляцию и иммутабельность журналов, автоматизируйте сверки и разбирательства. Тогда сеть получает проверяемость, быструю реакцию на инциденты и предсказуемый комплаенс при масштабировании по участникам и регионам.