Журнал действий пользователя: что должно фиксироваться в B2B-продукте

Полное руководство по audit log — от минимального набора событий до архитектуры, которая выдержит SOC 2, 152-ФЗ и корпоративный procurement

Почему audit log стал входным билетом на enterprise-рынок

Когда в 2025–2026 годах enterprise-покупатель оценивает B2B SaaS, security questionnaire приходит раньше коммерческого предложения. И почти всегда в нём есть один и тот же блок: «Покажите, как выглядит ваш журнал действий пользователя».

Команды, которые отвечают на этот вопрос скриншотами нескольких событий входа, теряют сделки — не потому что не прошли конкретный чекпоинт, а потому что сигнализируют: безопасность у нас не продумана системно [1].

Журнал действий пользователя (audit log, журнал аудита) — это хронологическая запись значимых событий, которая позволяет ответить на вопрос «кто, что, когда и с каким результатом сделал в системе» [6]. Это инструмент, которым пользуется сразу несколько аудиторий: ИБ-специалисты расследуют инциденты, SOC-команды детектируют аномалии, compliance-офицеры проходят проверки, а account admin клиента самостоятельно разбирается в том, что произошло внутри его организации [7].

Эта статья — практическое руководство для CTO, Tech Lead и команд, которые строят или дорабатывают audit log в B2B-продукте. Разберём: какие события фиксировать, какие поля обязательны для каждого события, как хранить логи так, чтобы им доверяли, и что требуют SOC 2 и российское законодательство.

Часть 1. Что такое audit log и чем он отличается от application log

Разграничение важно, потому что на практике команды часто путают два типа записей и строят неправильную архитектуру.

Application log — инструмент для инженеров. Он фиксирует, что делает система: stack traces, HTTP-статусы, время ответа запросов, ошибки приложения. Application log помогает отладить production-проблему.

Audit log — инструмент для людей, которые должны быть подотчётны. Он фиксирует, что делают пользователи и сервисы с системой: кто зашёл, кто изменил роль, кто экспортировал данные, кто удалил объект [8]. Audit log помогает расследовать инцидент, пройти аудит и объяснить клиенту, что именно произошло в его workspace.

Ключевые различия в подходе:

• Application log можно семплировать (10% запросов). Audit log семплировать нельзя — одно пропущенное событие может стать критическим доказательством.
• Application log содержит технический контекст. Audit log содержит бизнес-контекст: «Maria изменила роль Ahmed с viewer на admin», а не «row updated in users table».
• Application log разработчики могут менять и ротировать. Audit log должен быть защищён от изменения даже администраторами.

Хорошая метафора из инженерной практики: audit log — это чёрный ящик самолёта [5]. Его не покупают за красоту интерфейса. Но именно он становится главным документом, когда что-то пошло не так.

Часть 2. Минимальный набор событий: что фиксировать обязательно

2.1. Аутентификация: вход, провал, выход

Это базовый слой, без которого не существует ни одного корпоративного audit log.

Что фиксировать при успешном входе: идентификатор пользователя и email, org_id (для мультитенантных продуктов обязательно), метод аутентификации (password, sso_saml, sso_oidc, magic_link), идентификатор IdP-коннектора при SSO, IP-адрес, user_agent, страну, session_id, использовался ли MFA и какой метод [1].

Неудачный вход несёт больше информации, чем успешный: одна неудача — шум, десять неудач с разных IP за пять минут — credential stuffing атака. Поэтому к событию провала добавляйте: причину (invalid_credentials, account_locked, mfa_failed), количество попыток за последние N минут, флаг блокировки аккаунта [1].

Рекомендуемый срок хранения событий аутентификации: минимум 12 месяцев. SOC 2 требует этого, PCI DSS — тоже, причём с 3 месяцами в «горячем» хранилище для оперативного доступа [3].

Событие выхода из системы (logout) и принудительного завершения сессии также должны фиксироваться — это нужно для расследования сценариев, когда чужая сессия использовалась после компрометации.

2.2. Управление доступом: роли и разрешения

Изменения в ролях — это события с высоким blast radius. Если злоумышленник компрометирует аккаунт и назначает себе права admin, у вас должна быть точная запись: кто назначил, когда, кому, какую роль, и какая роль была до этого.

Что фиксировать: actor_user_id и actor_email (кто сделал изменение), target_user_id и target_email (над кем), предыдущая роль, новая роль, org_id, IP-адрес актора, timestamp [1].

Критически важно фиксировать не только успешные изменения, но и попытки, которые были отклонены системой. Отказ в праве может быть первым признаком попытки горизонтального перемещения внутри системы.

В мультитенантных продуктах нужно разграничивать: изменение роли внутри одного тенанта и изменение прав на уровне платформы (например, пользователь получил доступ к нескольким организациям). Это разные события с разными приоритетами оповещения.

2.3. Конфигурация SSO и SCIM

Это событие, которое большинство продуктов пропускают — и именно его в первую очередь проверяет опытная enterprise security team [1].

Если злоумышленник компрометирует admin-аккаунт и меняет SSO-конфигурацию, перенаправив аутентификацию на вредоносный IdP, у вас должна быть запись точного момента этого изменения, с полями before и after для критических атрибутов (ACS URL, metadata URL, IdP entity ID).

Аналогично для SCIM: создание, обновление и удаление пользователей через SCIM-провижнинг должны логироваться отдельными событиями с префиксом scim.*, что позволяет настроить единое правило оповещения для любой SCIM-активности вне рабочих часов [9].

Рекомендуемый срок хранения: 24 месяца. SSO-изменения редки, объём небольшой, но последствия незамеченного вредоносного изменения — катастрофические.

2.4. API-ключи и сервисные аккаунты

Каждый API-ключ — это долгоживущий credential, который может утечь. Enterprise security team хочет знать: когда ключ создан, кто его создал, к каким ресурсам он имеет доступ (scopes), когда последний раз ротировался, и когда истекает срок действия [9].

Особого внимания заслуживают ключи с признаком never_expires: true — это первое, что проверяет pentest-команда при оценке вашего продукта. Настройте алерт на создание такого ключа вне установленного IAM-процесса.

Полный жизненный цикл API-ключа в логах: создание, обновление (смена scopes, имени), отзыв, истечение срока, использование для критичных операций.

2.5. Экспорт данных

Экспорт данных — один из основных векторов утечки в SaaS-продукте. Запись «кто, что и в каком объёме выгрузил» критически важна для расследований в случае инцидента и для прохождения регуляторных проверок [1].

Что фиксировать: actor, org_id, тип данных (resource_type), количество записей (record_count), применённые фильтры, формат (csv, xlsx, json), назначение (browser_download, email, S3 bucket).

Рекомендуемый срок хранения: 24 месяца. Логи экспорта — доказательная база при расследовании утечки данных или регуляторном запросе [1].

Для SIEM: настройте алерт на экспорт с record_count, превышающим пороговое значение (например, 10 000 строк), особенно если назначение — нечёткое (личное хранилище, внешний email).

2.6. Биллинг и изменения плана

Изменения плана подписки, обновление платёжного метода, смена billing admin — это события с финансовыми последствиями, которые нужно фиксировать для защиты от мошенничества и для разрешения спорных ситуаций с клиентами.

Что фиксировать: actor, тип изменения (plan_upgraded, payment_method_updated, billing_admin_changed), предыдущее состояние, новое состояние, org_id. Само содержимое платёжных реквизитов (номер карты, CVV) в лог не пишется никогда — только маскированный идентификатор.

2.7. Разрушительные действия (delete, archive, restore)

Удаление объекта, архивирование, восстановление из архива — события, после которых чаще всего возникают вопросы «кто это сделал и почему».

Важный принцип: фиксируйте «мягкие удаления» (soft delete) как отдельное событие. Если в вашем продукте объект сначала помечается как удалённый, а потом физически удаляется — это два разных события с разными временными метками.

2.8. Административные действия платформы

Если у вас есть возможность impersonation (поддержка входит в аккаунт клиента) — это событие с наивысшим приоритетом логирования и оповещения. Enterprise-клиенты особенно чувствительны к этому: они должны знать, когда и почему сотрудник вендора получал доступ к их данным.

Что фиксировать: actor (внутренний пользователь), target_user_id, причина (support_ticket_id), timestamp начала и конца сессии, org_id клиента.

Часть 3. Структура события: обязательные поля

Каждое событие в audit log — это паспорт действия [5]. Оно должно путешествовать через вашу систему (SIEM, экспорт, архив) с достаточным контекстом, чтобы через 18 месяцев аналитик мог восстановить картину без доступа к другим данным.

Обязательные поля для любого события:

1. id — уникальный идентификатор события (UUID или ULID), неизменяемый.
2. tenant_id / org_id — идентификатор организации-клиента; в мультитенантной системе это обязательное поле для любого запроса [5].
3. actor_id — кто выполнил действие: user_id, service account ID, или system.
4. actor_type — тип актора: user, service, system.
5. action — стабильное, читаемое название действия: user.role_changed, api_key.created, report.exported. Паттерн: существительное + глагол [5].
6. target_type + target_id — над каким объектом выполнено действие.
7. result — success или failure. Отказы тоже логируются.
8. occurred_at — timestamp в UTC/ISO 8601. Все часы в системе должны быть синхронизированы с NTP, иначе временна́я последовательность событий при расследовании рассыпается.
9. ip_address — IP-адрес актора.
10. request_id — идентификатор запроса для корреляции с application log.
11. summary — небольшой объект с контекстом, специфичным для этого события: для смены роли — {oldRole, newRole}, для экспорта — {resource_type, record_count}.

Поле summary намеренно ограничено. Audit log — не склад всех данных транзакции. Если для события нужно хранить before/after, пишите только значимые атрибуты, а не полный дамп объекта [5].

Отдельный принцип для имён событий: они должны быть скучными в лучшем смысле слова [5]. Стабильные, специфичные, однозначные. Если вы мигрируете с REST на gRPC или переписываете сервис — имя события не должно меняться. Клиенты строят алерты и интеграции поверх ваших event names; переименование создаёт инциденты в чужих SIEM.

Часть 4. Что не пишем в лог

Эта часть не менее важна, чем предыдущая.

Secrets и credentials. Ни в каком виде. Ни raw, ни в base64, ни в хэшированном виде. Записывайте факт: api_key.created, webhook_secret.rotated, vault_policy.updated. Само значение секрета в лог не попадает никогда [5].

Содержимое документов, промпты AI, тело email. Audit log фиксирует факт доступа к ресурсу, а не его содержимое.

Полные платёжные данные. Только маскированный идентификатор карты (last4, bin) — и то только если это необходимо для расследования.

Сырые пароли. Очевидно, но встречается в production-системах чаще, чем хотелось бы.

Избыточный PII. Предпочитайте стабильные ID вместо email-адресов там, где это возможно. Это упрощает соответствие GDPR и 152-ФЗ: при запросе на удаление данных пользователя из GDPR/152-ФЗ вам не нужно «чистить» исторические логи — ID деперсонализирован [5]. При этом поле actor_email всё равно нужно для оперативной читаемости; баланс зависит от вашей политики хранения.

Часть 5. Неизменяемость: почему это не опция

Audit log работает только если ему доверяют. Доверие разрушается в тот момент, когда выясняется, что admin мог удалить или отредактировать запись.

Требование неизменяемости фиксируется в нескольких стандартах и практиках [2]:

• WORM (Write Once, Read Many) — технический механизм, при котором данные записываются один раз и не могут быть изменены в течение retention period. На AWS это S3 Object Lock в compliance mode; на Azure — immutable blob storage.
• Hash chains — каждое новое событие включает хэш предыдущего. Попытка изменить любое событие в цепочке разрывает её и становится детектируемой.
• Криптографические подписи — AWS CloudTrail подписывает каждый лог-файл; можно верифицировать, что файл не был изменён после доставки.

Важный принцип для мультитенантного продукта: только узкоспециализированный сервисный аккаунт имеет право писать в audit log. Product admin может читать события своего тенанта. Никто — ни product admin, ни platform admin — не может редактировать или удалять события [5].

Удаления в audit log не существует. Когда пользователь удаляет свои данные (GDPR/152-ФЗ), запись о самом факте удаления остаётся. Это корректно и соответствует требованиям: вы удалили данные, сам факт удаления подлежит аудиту.

Часть 6. Хранение и retention: сколько держать логи

Разные регуляторные режимы предъявляют разные требования — но они не противоречат друг другу при правильной настройке [10].

SOC 2 не задаёт конкретных сроков, но аудитор ожидает, что логи покрывают весь observation period плюс буфер. Для ежегодного Type II аудита это значит: нужно хранить минимум 13–15 месяцев [3]. Практический ориентир для системы с горячим и холодным хранилищем:

• Горячее хранилище (queryable): последние 90 дней для оперативного расследования.
• Тёплое хранилище: 90 дней — 13 месяцев, с задержкой поиска в пределах минут.
• Холодное хранилище (архив): 13–24+ месяцев, WORM, доступ по запросу.

PCI DSS 4.0 требует 12 месяцев для событий, связанных с card data, с 3 месяцами в «горячем» хранилище [1].

GDPR вводит конкурирующий принцип — хранить данные не дольше, чем необходимо. Recital 49 и Article 32 делают исключение для security purposes [10]. Это значит: аудит-логи для детекции инцидентов вы вправе хранить в разумных пределах. «На всякий случай навсегда» — не валидная GDPR-цель. Практическое решение: GDPR-purpose для логов — security monitoring; retention 12–24 месяца с документально закреплённым обоснованием.

Российское регулирование (152-ФЗ + ФСТЭК). Статьи 18.1 и 19 152-ФЗ требуют вести учёт обращений к персональным данным и проводить внутренние аудиты не реже одного раза в год [4]. Приказы ФСТЭК конкретизируют технические меры защиты для информационных систем персональных данных (ИСПДн) в зависимости от уровня защищённости. Если ваш B2B-продукт обрабатывает ПДн российских граждан — журналы доступа к этим данным обязательны, и их соответствие проверяется при внеплановых проверках Роскомнадзора, активность которых значительно выросла в 2023–2025 годах [4].

Tiered storage — стандартная практика для оптимизации стоимости:

1. Горячее: последние 30–90 дней — fast query, дорого.
2. Тёплое: 3–13 месяцев — медленнее, дешевле.
3. Холодное: 13+ месяцев — объектное хранилище с WORM, минимальная стоимость.

Ключевое правило: не семплируйте audit events. Если вы потеряли один экспорт, который нужен клиенту — это memorable meeting с вашей командой продаж и юристами [5].

Часть 7. Мультитенантность: изоляция обязательна

В мультитенантном B2B-продукте каждое событие должно содержать tenant_id. Каждый запрос к API журнала должен фильтроваться по нему. Каждый экспорт должен быть скопирован только для конкретного тенанта [5].

Это не просто архитектурная рекомендация — это требование безопасности и доверия. Клиент должен видеть только события своей организации. Ваша команда поддержки может просматривать события тенанта при наличии явно залогированного запроса (impersonation event).

Практически это значит: при любом запросе к audit log добавляйте tenant_id как обязательный параметр фильтрации на уровне инфраструктуры, не полагаясь на то, что API-клиент правильно передаст его. Ошибка здесь = один тенант видит события другого = катастрофа доверия.

Добавьте индекс на (tenant_id, occurred_at) — самый частый паттерн запроса от admin-пользователя: «покажи последние события в моём workspace» [5].

Часть 8. Доступ к логам: интерфейс для клиента и интеграции

Audit log работает только если клиент может им пользоваться. Это означает несколько вещей.

UI внутри продукта. Account admin должен видеть события своей организации с фильтрами по пользователю, типу события, временному диапазону и IP-адресу. Время загрузки типового запроса — единицы секунд; задержка в 5+ минут делает инструмент бесполезным для расследования инцидентов [7].

Экспорт. CSV и JSON минимум. Enterprise-клиенты хотят забрать данные в свою SIEM. Если у вас нет экспорта в machine-readable формате — ваш audit log не пройдёт enterprise security review.

Webhook / streaming. Для зрелых продуктов: push-нотификации в реальном времени или near-real-time, которые клиент может подписать на свой Splunk, Datadog, Elastic. Это и есть «интеграция с SIEM» из enterprise-чеклиста.

API для программного доступа. Клиент должен иметь возможность получать события через API: по тенанту, по типу события, по временному диапазону. Pagination обязателен.

Self-service для клиента — это снижение нагрузки на вашу поддержку. Один CTO из enterprise-практики описывал это так: внедрение детального audit log сократило поток support-тикетов на тему «кто это сделал» — клиенты стали отвечать на этот вопрос самостоятельно [11].

Часть 9. Compliance и стандарты: что конкретно требуют

SOC 2 Trust Service Criteria

Ключевые критерии, требующие audit logging [3]:

• CC6.1: логирование доступа к данным, включая аутентификацию и привилегированный доступ.
• CC7.2: мониторинг системных событий на предмет аномалий.
• CC7.3: оценка инцидентов безопасности.
• CC8.1: контроль изменений конфигурации.

SOC 2 не задаёт исчерпывающий список событий — он требует, чтобы события были «достаточно детализированы для поддержки расследований и установления ответственности» [3].

Логи, которые никто не читает, — не контроль. SOC 2 требует, чтобы вы могли показать: кто их читает, как часто, и что происходит при обнаружении аномалии [3].

PCI DSS 4.0

Требует логировать: все попытки доступа к данным держателей карт, все admin-действия, все попытки доступа к audit log, неудачную аутентификацию. Retention: 12 месяцев с 3 месяцами в горячем хранилище [1].

GDPR / 152-ФЗ

Оба режима требуют соразмерного и обоснованного хранения данных. Логируйте только то, что необходимо; уничтожайте данные по истечении установленного срока автоматически. Факт уничтожения сам должен быть залогирован [10].

Для 152-ФЗ: ведите журналы учёта обращений к персональным данным, как предписывают статьи 18.1 и 19 Закона. Роскомнадзор при проверке запрашивает доказательства того, что такие журналы ведутся и проверяются [4].

Часть 10. Типичные ошибки и как их избежать

Ошибка 1. Логировать только UI-события, игнорировать API-вызовы. Если у вашего продукта есть API, любое действие через него должно также фиксироваться. Enterprise-клиенты активно используют API для автоматизации — и именно API-активность чаще всего интересует security team при расследовании.

Ошибка 2. Логировать нажатия на кнопки вместо бизнес-решений. «Пользователь кликнул на кнопку Delete» — не событие. «Пользователь удалил project X» — событие. Emit-точка должна быть максимально близко к бизнес-логике, не к UI [5].

Ошибка 3. Фиксировать только успехи, игнорировать отказы. Отказанные попытки — часто первый сигнал атаки. Отказ в доступе к admin-панели, отказ при попытке изменить роль, многократный failed login — всё это должно фиксироваться с тем же приоритетом, что и успешные действия [8].

Ошибка 4. Не синхронизировать часы. Если часы на разных сервисах расходятся, временна́я последовательность событий при расследовании разваливается. Используйте единый NTP-источник для всей инфраструктуры [2].

Ошибка 5. Хранить секреты в логах. Встречается реже, чем кажется, но последствия серьёзные: audit log — долгоживущая запись, которую читает много людей. Даже хэш пароля в логе — плохая практика.

Ошибка 6. Разрешить администраторам редактировать логи. Даже «хорошим» администраторам. Audit log должен быть append-only на уровне инфраструктуры; это основа доверия к нему как к доказательной базе [2].

Ошибка 7. Не давать клиенту доступа к его собственным логам. Audit log без UI и API экспорта — это внутренний инструмент, который не закроет enterprise procurement. Клиенту нужен self-service доступ [11].

Часть 11. Архитектурный минимум для production

Жизненный цикл события в правильно спроектированной системе [7]:

1. Resolve actor и tenant — определяем, кто делает действие и в контексте какой организации.
2. Check permission — проверяем право на действие.
3. Выполняем бизнес-действие.
4. Пишем audit event — эмиттим событие атомарно с результатом действия (success или failure).

Эмиттировать событие нужно после выполнения действия, но в той же транзакции или через transactional outbox pattern, чтобы избежать ситуации «действие выполнено, лог потерян».

Только специализированный сервисный аккаунт пишет в хранилище audit log. Приложение эмиттит событие в очередь (Kafka, SQS, Pub/Sub); consumer записывает в append-only хранилище. Это разделение обеспечивает: приложение не может редактировать историческую запись, даже если в нём есть уязвимость.

Для мультитенантного продукта: хранилище должно поддерживать эффективную фильтрацию по (tenant_id, occurred_at) и экспорт по тенанту. PostgreSQL подходит для большинства продуктов на ранних и средних стадиях; при росте объёма — тиered переход к object storage (S3, GCS) с WORM.

Что делать дальше: чек-лист

Перед merge/release любой новой функции с пользовательскими действиями:

1. Определить, какие события эта функция порождает. Добавить их в audit log schema.
2. Проверить, что event name стабилен и следует конвенции noun.verb.
3. Убедиться, что tenant_id присутствует в каждом событии.
4. Проверить, что отказы фиксируются так же, как успехи.
5. Убедиться, что секреты и PII не попадают в поле summary.
6. Проверить, что emit-точка находится рядом с бизнес-логикой, а не в UI.
7. Убедиться, что событие уходит в append-only хранилище через выделенный сервисный аккаунт.

Для команды, которая строит audit log с нуля:

1. Определить storage tier: горячее (90 дней), тёплое (13 месяцев), холодное (24+ месяца).
2. Включить WORM или hash chains на уровне хранилища.
3. Реализовать минимальный набор событий из Части 2.
4. Добавить UI для account admin с фильтрами и экспортом.
5. Задокументировать retention policy с обоснованием для каждого типа данных (для GDPR/152-ФЗ).
6. Настроить синхронизацию часов (NTP) на всей инфраструктуре.
7. Убедиться, что ни один admin не может удалить или отредактировать событие.

Заключение

Audit log — это не инфраструктурный технический долг, который можно отложить «на потом». Это часть продуктового контракта с enterprise-клиентом, базовый инструмент безопасности и доказательная база, которая работает только если ей доверяют.

Проверенные паттерны просты: каждое событие отвечает на пять вопросов (кто, что, над чем, когда, с каким результатом), лог неизменяем, доступ изолирован по тенантам, клиент может самостоятельно экспортировать данные.

Те команды, которые строят audit log проактивно, а не как ответ на замечание аудитора, обнаруживают интересный эффект: полноценный журнал действий сокращает цикл enterprise-продажи и снижает нагрузку на поддержку — потому что клиент сам отвечает на вопрос «кто это сделал» [11].

Источники

[1] SSOJet — "10 Critical Audit Log Events Every B2B SaaS App Should Track for Enterprise Buyers" — https://ssojet.com/blog/critical-audit-log-events-b2b-saas-enterprise

[2] Sonar — "Audit Logging Best Practices, Components & Challenges" — https://www.sonarsource.com/resources/library/audit-logging/

[3] AuditKit — "SOC 2 Audit Log Requirements: Complete Checklist for SaaS" — https://auditkit.dev/blog/soc-2-audit-log-requirements

[4] ic-tech.ru — "Перечень документов по 152-ФЗ для организации в 2025 году" — https://ic-tech.ru/blog/knowledge-base/pdn-152fz-2025/

[5] AverageDevs — "Designing Audit Logs for SaaS: Evidence, Security, and Product Trust" — https://www.averagedevs.com/blog/audit-logs-saas-compliance-trust

[6] MWS Cloud / Habr — "Сервис аудитных логов в облаке: архитектура и ценность для пользователей" — https://habr.com/ru/companies/mws/articles/1031812/

[7] MWS Cloud / Habr — там же (требования к производительности, сценарии расследований)

[8] Berkeley Information Security Office — "Security Audit Logging Guideline" (source: NIST SP 800-92) — https://security.berkeley.edu/security-audit-logging-guideline

[9] Security Boulevard — "10 Critical Audit Log Events Every B2B SaaS App Should Track for Enterprise Buyers" — https://securityboulevard.com/2026/04/10-critical-audit-log-events-every-b2b-saas-app-should-track-for-enterprise-buyers/

[10] Stack Harbor — "Audit-log retention policy that satisfies SOC 2, PIPEDA and GDPR in one configuration" — https://stackharbor.com/en/knowledge-base/audit-log-retention-multi-regime-config/

[11] Deepak Gupta — "Enterprise Readiness Playbook: Scale Your B2B SaaS in the Enterprise" — https://guptadeepak.com/the-enterprise-readiness-playbook-transform-your-b2b-saas-from-startup-to-enterprise-grade/

[12] AuditPath — "SOC 2 Audit Log Requirements: What Needs to Be Logged" — https://www.auditpath.io/blog/soc2-audit-log-requirements

[13] SecurityDocs — "SOC 2 Logging and Monitoring Requirements: What You Need to Capture" — https://security-docs.com/blog/soc2-logging-monitoring

[14] PWNSentinel — "Ensuring Compliance with Tamper-Proof Logging in AWS & Azure" — https://pwnsentinel.org/2025/07/18/tamper-proof-logging/

[15] Hashorn — "Enterprise-Ready SaaS: SSO, SCIM, and Audit Logs in the Right Order" — https://hashorn.com/blog/enterprise-ready-saas-sso-scim-audit-logs