Перейти к содержанию

Audit trails, lineage и retention

Раздел 04 · Типы достоверности

Тип материала: инженерный разбор. Схемы и примеры иллюстративные. Рекомендации — INFERENCE; учебные параметры — HYPOTHETICAL.

Проверка источников: 2026-11-02. Версии и границы первоисточников перечислены в конце. Documented contracts не означают выполненный runtime test.

Принцип работы и границы

Audit trail отвечает «кто и на каком основании изменил состояние», lineage — «из каких inputs и какой версией кода получен dataset». Оба требуют identity, времени, actor, provenance и контроля доступа; обычный application log с sampling может быть неполным.

INFERENCE: связывайте business operation с immutable posting, source cut, transformation version и published generation. Обновление исправляется новой записью с reference на оригинал, а не исчезающей правкой истории. Integrity controls, например append-only ACL и hash chains, требуют защиты ключей и checkpoints доверия: один hash без независимого хранения не доказывает неизменность.

Retention определяется назначением, обязательствами и replay horizon. FACT: GDPR storage limitation требует не хранить персональные данные дольше необходимого для цели; European Commission. Это не фиксированный универсальный срок и не разрешение удалить финансовые evidence вопреки установленным обязательствам.

Иллюстративная архитектура

flowchart LR
 E[Business event] --> A[Protected audit record]
 E --> L[Lineage: cut, code, schema, generation]
 A --> P[Retention and access policy]
 L --> P
 P --> R[Archive, legal hold or controlled disposal]

Failure scenarios

Audit sink недоступен, а приложение продолжает irreversible операции без согласованного policy. Архив существует, но schema/code versions удалены. Rebuild восстанавливает ранее удалённую PII. Admin меняет бизнес-таблицу и audit в той же незащищённой DB, оставляя ложное evidence.

Recovery protocol

  1. Определить утраченный interval audit/lineage и остановить операции, требующие его completeness.
  2. Восстановить evidence из независимых source/ledger records; отметить реконструированные части явно.
  3. Проверить ACL, integrity checkpoints и actor attribution.
  4. Применить retention/erasure policy ко всем generations, DLQ, caches и restore workflow.
  5. Зафиксировать unresolved provenance; технический repair не объявлять юридическим подтверждением полноты.

Trade-offs и критерии выбора

Полная история повышает recoverability, но увеличивает privacy и access burden. Минимизация payload требует отдельно хранить безопасные идентификаторы. WORM защищает от части изменений, но не доказывает истинность исходной записи или достаточность legal scope.

FinTech и iGaming

Ledger audit связывает operator correction с approved reason и исходной операцией. Для ставок сохраняются версия расчёта, результат события и основание re-settlement. Документы KYC не следует копировать в каждый event ради lineage.

Практический пример

Учебный manifest: dataset_id, generation, source_cut, source_hash, schema_version, code_revision, checked_at, operator_reference. Сопоставьте его с reporting helpers. При restore повторно примените действующую suppression/erasure policy до открытия serving.

Типичные ошибки проектирования

Считать audit log compliance certificate; хранить PII бессрочно «для replay»; забывать backup copies; менять retained record без correction link; lineage без версии бизнес-правил.

Вопросы на собеседовании

Доказывает ли hash chain полный аудит? Он выявляет некоторые изменения при доверенном anchor, но не гарантирует, что все события изначально записаны.

Что если retention marker короче replay horizon? Возможно повторное применение и восстановление запрещённых данных; policies должны согласовываться.

Дополнительные источники