Хватит ли аудит-логов без текста запросов при утечке PII?

Аудит-логи без текста запросов обычно достаточны, чтобы установить цепочку действий: кто отправил вызов, каким ключом, под какой политикой, куда его направили и чем закончилась проверка доступа. Они не позволяют восстановить точную строку с ИИН, телефоном или диагнозом. Если расследование должно ответить именно на вопрос «какие персональные данные ушли», одних метаданных не хватит.

Это не довод в пользу постоянной записи тел запросов. Такой журнал часто создает вторую утечку рядом с первой: доступ к логам шире, срок хранения длиннее, а копии расходятся по поисковому индексу, SIEM и резервным архивам. Я предпочитаю заранее разделить три задачи: связать события, подтвердить применение контроля и при необходимости сопоставить конкретный секрет с событием, не сохраняя весь запрос открытым текстом.

Метаданные доказывают событие, но не его содержание

Без текста можно уверенно доказать только то, что выражено отдельными полями. Запись вида 200 POST /chat/completions почти бесполезна: она не связывает вызов с человеком, не показывает фактический маршрут и ничего не говорит о маскировании. Хорошая запись отвечает на шесть вопросов независимо от тела: кто действовал, через какое полномочие, какая политика сработала, куда ушел запрос, когда это произошло и какой контроль разрешил или остановил операцию.

Здесь команды часто смешивают наблюдаемость и аудит. Метрики нужны, чтобы увидеть рост ошибок или задержки. Трассировка связывает работу нескольких сервисов. Аудит фиксирует действие субъекта и решение контроля так, чтобы запись выдержала внутреннюю проверку. Один trace_id полезен во всех трех слоях, но сам по себе он не превращает технический спан в доказательство.

Граница простая. Метаданные позволяют сказать: «пользователь 42 через ключ с отпечатком k_7f3a отправил запрос, политика pii-kz-v4 нашла один ИИН, заменила его токеном, после чего шлюз направил вызов в локальный пул и получил ответ». Они не позволяют сказать, какой именно ИИН был найден. Эту разницу надо записать в плане реагирования до инцидента, иначе на разборе от журнала потребуют невозможного.

Поле с количеством найденных сущностей тоже не доказывает отсутствие PII. Нулевой результат означает лишь, что конкретная версия детектора ничего не нашла при конкретных настройках. Это свидетельство работы контроля, а не сертификат чистоты текста.

Идентичность пользователя и ключа надо хранить раздельно

Минимальная запись содержит стабильный actor_id и отпечаток API-ключа. Идентификатор пользователя отвечает за человеческого или сервисного владельца действия, а отпечаток ключа показывает, каким полномочием воспользовались. Если хранить только одно из них, расследование упрется либо в общий технический аккаунт, либо в ключ, который уже удалили из рабочей базы.

Не записывайте сам секрет, даже частично в форме, из которой его можно угадать. Рассчитайте необратимый отпечаток при выпуске ключа, например HMAC от полного ключа с отдельным серверным секретом, и сохраните результат рядом с записью о владельце. Обычный быстрый хеш слаб для токенов с низкой энтропией или известным префиксом, а HMAC не дает проверять догадки без секретного ключа. В аудит передавайте короткий идентификатор записи ключа и полный отпечаток фиксированной длины.

Связь владельца нельзя вычислять только во время расследования. Пользователь мог уйти, сервисный аккаунт могли переименовать, а ключ могли перевыпустить. Поэтому событие должно содержать actor_id, actor_type, tenant_id и key_id такими, какими они были в момент вызова. Имя и адрес почты лучше не дублировать: они меняются и сами относятся к персональным данным. Историю соответствий храните в защищенном реестре управления доступом.

Полезно различать инициатора и делегата. Вызов от фонового агента может иметь actor_id сервиса, но on_behalf_of пользователя, запустившего задачу. Без второго поля десять тысяч автоматических запросов будут выглядеть как действия одного безликого процесса. Если делегирования нет, поле должно иметь явное значение null, а не исчезать случайным образом.

Для расследования компрометации добавьте auth_context: способ аутентификации, идентификатор сессии, результат проверки и код причины. Не надо складывать туда IP как замену личности. NAT, мобильные сети и прокси делают IP слабым атрибутом, хотя отдельное нормализованное поле источника остается полезным сигналом.

Версия политики важнее флага «маскирование включено»

Флаг masking=true почти ничего не доказывает. Следователю нужны идентификатор политики, ее неизменяемая версия, режим выполнения и результат. Политика с тем же именем могла вчера искать ИИН, а сегодня только телефоны; режим мог быть настроен на наблюдение без изменения текста.

Записывайте как минимум policy_id, policy_version, policy_digest, enforcement_mode и policy_decision. Идентификатор помогает найти правило, версия указывает на снимок конфигурации, а digest обнаруживает тихую правку файла под прежним номером. Режим должен различать monitor, redact, block и bypass. Решение удобно ограничить значениями allow, deny, allow_after_redaction и error.

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

{"policy_id":"pii-kz","policy_version":4,"policy_digest":"sha256:8c...","enforcement_mode":"redact","detector_version":"ner-12","findings":{"iin":1,"phone":0},"action":"tokenize","decision":"allow_after_redaction"}

Такой объект отвечает на вопрос, какой контроль применили, но не выдает значение ИИН. Он также показывает важную ошибку конфигурации: findings.iin=1 вместе с enforcement_mode=monitor означает, что система увидела данные и сознательно пропустила их без маскирования.

Политику иногда обходят по утвержденному исключению. Не прячьте это внутри общего allow. Добавьте exception_id, владельца исключения и срок действия, причем сам текст обоснования можно хранить в системе согласований. В журнале достаточно ссылки по внутреннему идентификатору. Для аварийного обхода запишите отдельный код причины и факт усиленного контроля доступа.

Ошибка детектора не равна чистому результату. Если сервис маскирования не ответил, событие должно получить policy_decision=error и конкретный failure_code. Конфигурация шлюза затем определяет, закрывать ли запрос. В системах с чувствительными данными я выбираю отказ, потому что разрешение при неизвестном результате превращает сбой проверки в канал утечки.

Фактический маршрут нельзя восстанавливать из конфигурации задним числом

Запрашиваемая модель и фактическое направление часто расходятся. Роутер может выбрать другого провайдера из-за недоступности, лимита, региона, цены или правила резидентности. Поэтому аудит должен фиксировать решение маршрутизации в самом событии, а не предлагать следователю воспроизвести старую конфигурацию.

Минимальный набор включает requested_model, resolved_model, route_id, provider_id, endpoint_class, processing_region и residency_policy. Если запрос прошел через несколько попыток, одной финальной строки мало. Создайте дочернее событие на каждую попытку с общим request_id, последовательным attempt_no и собственным результатом. Тогда неудачная первая отправка внешнему провайдеру не исчезнет за успешным повтором на локальной модели.

Не записывайте полный адрес провайдера с параметрами, если он может содержать секреты. Нормализованный provider_id и класс конечной точки обычно дают достаточно контекста. Для частного развертывания полезны идентификатор кластера и зона, но имя узла редко помогает в аудите и заметно увеличивает кардинальность.

Правило резидентности надо фиксировать как примененное решение, например kz_only:v3, плюс результат matched или violated. Поле региона, заполненное самим приложением, слабее записи пограничного шлюза: приложение может ошибаться или не знать о повторной маршрутизации. Источник каждого существенного поля должен быть однозначен.

AI Router уместен в такой схеме как единая точка, где можно связать маршрут к провайдеру или локальной модели с маскированием PII и аудит-событием. Но наличие шлюза не исправляет плохой контракт журнала: команда все равно должна заранее определить поля, версии и правила доступа к ним.

Время требует границ, часов и порядка событий

Одной временной метки недостаточно, если запрос проходил проверку, очередь, маршрутизацию и несколько попыток. Сохраняйте received_at, policy_checked_at, dispatched_at и completed_at в UTC с точностью, которую реально поддерживает платформа. Для длительностей используйте монотонные часы внутри процесса, потому что корректировка системного времени может сделать разницу между двумя календарными метками отрицательной.

Каждая запись должна иметь уникальный event_id, стабильный request_id и распределенный trace_id. W3C Trace Context определяет перенос traceparent между сервисами, но не обещает, что этот идентификатор аутентифицирован или пригоден как единственный аудиторский ключ. Принимайте входной trace-контекст для трассировки, а собственный request_id выдавайте на доверенной границе и не разрешайте клиенту его подменять.

Порядок удобно закрепить локальным sequence_no для событий одного запроса. Это помогает, когда пакетная доставка меняет порядок строк в хранилище. Между разными сервисами не пытайтесь изобразить абсолютную последовательность с точностью до микросекунды. Храните известную погрешность синхронизации часов и опирайтесь на причинные идентификаторы: родительский спан, номер попытки и ссылку на предыдущее событие.

Время приема нужно брать до разбора тела, иначе авария парсера оставит вызов без начала. Завершение пишите для каждого исхода, включая таймаут клиента и внутреннее исключение. Если процесс погиб до финальной записи, отдельный контроль доставки должен пометить незакрытый запрос. Отсутствие completed_at тогда становится наблюдаемым состоянием, а не двусмысленной дырой.

Срок хранения также входит в модель доказательств. Если события живут семь дней, расследование на восьмой день не восстановит цепочку. Выберите срок по времени обнаружения и внутренним обязательствам, зафиксируйте его в политике, а удаление подтверждайте собственным событием управления журналом. Не обещайте расследуемость дольше, чем хранится самый короткоживущий элемент цепочки.

Результат доступа должен объяснять решение

HTTP-статус описывает ответ клиенту, но не объясняет решение контроля. 403 может прийти от шлюза, провайдера или приложения; 200 может сопровождать ответ модели, которая отказалась выполнять запрос. Для аудита доступа нужны отдельные поля access_decision, decision_source, reason_code и evaluated_permissions.

Коды причин должны быть стабильными и машиночитаемыми: KEY_REVOKED, TENANT_MISMATCH, MODEL_NOT_ALLOWED, RESIDENCY_BLOCK, RATE_LIMIT или POLICY_SERVICE_ERROR. Человеческое сообщение можно добавить, но на него нельзя строить запросы расследования: формулировка изменится после следующего релиза. Не помещайте в сообщение часть исходного запроса или значение токена.

Список проверенных разрешений лучше записывать как компактный снимок, например llm.invoke, model.external.use и pii.redaction.required, вместе с версией набора ролей. Простого результата allow мало, когда через месяц администратор изменит роль. Снимок не обязан копировать всю IAM-политику, но должен позволять восстановить, какое правило дало доступ.

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

Событие отказа надо писать до возврата ответа клиенту через канал, который не зависит от того же сбойного компонента. Иначе перегруженный сервис проверки будет одновременно пропускать мало данных и терять записи о собственных ошибках. Для критичных решений практичнее локальная очередь с подтверждением доставки и счетчиком потерянных событий.

Отпечаток содержимого помогает только при четкой модели угроз

Команда может сопоставлять известное значение PII с событием, не сохраняя тело, если журнал содержит защищенный отпечаток нормализованного значения. Например, детектор извлекает ИИН, приводит его к канонической форме и вычисляет HMAC в отдельном домене ключей. Во время расследования уполномоченный процесс повторяет операцию для известного ИИН и ищет совпадение.

Это не универсальный хеш всего запроса. Пробел, порядок полей или служебная инструкция изменят хеш тела, хотя персональные данные останутся теми же. Обычный SHA-256 от ИИН опасен: пространство возможных значений ограничено, поэтому атакующий с журналом может перебрать кандидатов. HMAC снижает этот риск, если секрет хранится вне системы логов и доступ к операции сравнения тоже аудируется.

Минимальная схема для находки выглядит так:

{"entity_type":"iin","fingerprint":"hmac-sha256:v2:ab...","normalization":"iin-digits-v1","key_version":2,"match_scope":"tenant"}

key_version нужен для ротации, а match_scope не дает случайно искать одного человека по всем арендаторам. Сами отпечатки остаются чувствительными: они создают устойчивую связь между событиями. Ограничьте доступ, установите отдельный срок хранения и не отправляйте их в обычные панели разработчиков.

Если следователю надо увидеть контекст вокруг значения, отпечаток не поможет. Тогда нужен отдельный хранилищный контур доказательств: выборочная запись по строгому триггеру, шифрование отдельным ключом, двухстороннее согласование доступа и короткий срок жизни. Такой контур нельзя включать постоянно «на всякий случай». Он должен собирать ровно тот материал, который разрешен политикой расследования.

Я также не советую шифровать все тела и считать задачу решенной. Шифрованный архив остается архивом персональных данных, требует управления ключами, удаления копий и учета каждого чтения. Он оправдан, когда правовой и операционный сценарий требует реконструкции, а не потому, что команда не договорилась о полях аудита.

Минимальный контракт события должен быть проверяемым

Хороший минимальный набор можно уложить в один версионируемый объект. «Минимальный» здесь означает отсутствие поля, которое не меняет ни один вывод расследования. Это не означает короткую строку без контекста.

{"schema_version":3,"event_id":"evt_01...","request_id":"req_01...","trace_id":"4bf92f...","sequence_no":4,"received_at":"2026-07-27T10:15:12.184Z","completed_at":"2026-07-27T10:15:12.941Z","actor":{"tenant_id":"t_17","actor_id":"u_42","actor_type":"human","on_behalf_of":null},"credential":{"key_id":"key_9","fingerprint":"hmac-sha256:7f3a..."},"auth":{"method":"api_key","decision":"allow","reason_code":"ROLE_MATCH","role_set_version":8},"pii":{"policy_id":"pii-kz","policy_version":4,"policy_digest":"sha256:8c...","mode":"redact","detector_version":"ner-12","findings":{"iin":1},"decision":"allow_after_redaction"},"route":{"requested_model":"model-a","resolved_model":"model-b","route_id":"kz-local","provider_id":"local-pool","processing_region":"kz","residency_policy":"kz_only:v3"},"result":{"status_class":"2xx","error_code":null,"input_tokens":812,"output_tokens":144}}

Проверьте контракт автоматическими тестами, а не ревью документа. Тест должен отправить разрешенный вызов, заблокированный вызов, сбой детектора и повторную маршрутизацию, затем убедиться, что для каждого пути появилась запись с обязательными полями. Еще один тест удаляет или переименовывает ключ после события и проверяет, что связь с прежним владельцем остается доступной через защищенную историю.

Полезна и проверка отрицательных условий. В журнале не должны появляться Authorization, исходный prompt, полный ответ модели, адрес почты или извлеченное значение PII. Сканер секретов для самого потока логов стоит запускать до индексации. Если он сработал, карантин должен остановить распространение записи по вторичным системам.

Версия схемы обязательна. Добавляйте поля совместимо, а изменение смысла выпускайте новой версией. OpenTelemetry хорошо переносит trace-контекст и технические атрибуты, но его семантические соглашения не заменяют ваш договор об идентичности, решении политики и сроках хранения. Эти поля принадлежат вашей модели угроз, поэтому владелец безопасности должен утверждать их явно.

Целостность журнала и доступ к нему входят в доказательство

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

Защита от изменений не сводится к метке immutable. Полезна цепочка хешей внутри упорядоченной партии: каждое событие содержит хеш предыдущего, а итог партии подписывает отдельный сервис. Периодически сохраняйте подписанный корень в другом административном домене. Тогда удаление или правка строки оставит проверяемый разрыв, хотя такая схема не докажет, что приложение изначально отправило правдивые поля.

Именно источник определяет вес записи. actor_id, который прислал недоверенный клиент, нельзя считать установленной личностью. Шлюз должен получить его из проверенного контекста аутентификации. Результат маскирования пишет сервис политики, а фактического провайдера фиксирует компонент, открывший исходящее соединение. В схеме стоит документировать производителя каждого поля и границу, на которой ему начинают доверять.

Чтение журнала тоже создает риск утечки. Разделите роли поиска по метаданным, сопоставления HMAC-отпечатков и доступа к защищенным телам. Обычный оператор может искать по request_id и кодам решений, но не должен видеть устойчивые отпечатки людей из других арендаторов. Выгрузка большого диапазона требует отдельного разрешения и причины обращения.

Каждый поиск и экспорт запишите во второй аудит-контур: кто выполнил запрос, по какому делу, какие поля запросил, сколько строк получил и куда ушел файл. Не копируйте в этот метажурнал сами результаты поиска. Иначе контроль доступа к первому хранилищу легко обходится через менее защищенную историю запросов.

Доступность важна не меньше неизменности. Если доставка асинхронная, отслеживайте последнее подтвержденное смещение очереди, возраст старейшего события и число строк в карантине. Алерт на потерю аудит-событий должен сработать отдельно от алерта приложения. Сбой продукта не может быть оправданием для невидимого провала журнала в тот же период.

Резервная копия должна сохранять ограничения доступа и срок удаления. Я видел схемы, где основной индекс честно очищался через месяц, а неограниченный архив жил годами в учетной записи инфраструктуры. Расследуемость от этого почти не улучшалась, зато объем возможной утечки рос. Проверьте удаление восстановлением тестовой копии и поиском истекшего event_id.

Наконец, регулярно сверяйте число принятых запросов с числом терминальных аудит-событий по арендатору и временному окну. Значения не всегда совпадут один к одному из-за ранних отказов и повторных попыток, поэтому сравнивайте ожидаемые переходы состояний, а не только общую сумму. Необъяснимый разрыв означает, что расследование уже потеряло часть цепочки, даже если инцидента пока никто не заметил.

Доступ к часам, конфигурации сборщика и ключу подписи также разделяйте. Оператор приложения не должен одновременно менять политику, останавливать экспорт и переподписывать партию событий. Когда полного разделения обязанностей нет, хотя бы требуйте независимого подтверждения для этих операций и немедленно отправляйте уведомление владельцу безопасности. В журнале управления сохраняйте старое и новое значения, автора, согласующего и связанный номер изменения.

Проверку целостности запускайте по расписанию и при каждом экспорте для расследования. Она должна пересчитать цепочку, проверить подписи партий, найти пропуски последовательности и сравнить фактический срок хранения с заявленным. Отчет без ошибки еще не означает полноту, поэтому рядом показывайте ожидаемое и принятое количество событий по каждому источнику. Такой контроль превращает обещание «логи у нас есть» в проверяемое состояние.

Не отправляйте сырые аудит-события напрямую во все аналитические системы. Сначала отделите поля для оперативных панелей от полей для расследования, затем выдайте каждой системе собственное представление. Счетчики статусов и задержки можно агрегировать, а отпечатки ключей, идентификаторы субъектов и детали исключений оставить в защищенном индексе. Чем меньше копий несут устойчивые идентификаторы, тем проще доказать, кто мог их прочитать.

Расследование надо репетировать до утечки

Представим, что служба безопасности получила ИИН, найденный в ответе внешнего провайдера, и временной диапазон в двадцать минут. Сначала следователь вычисляет разрешенный HMAC-отпечаток известного значения и ищет совпадения только в нужном арендаторе. Если отпечатков нет, он фильтрует события по типу находки iin, времени, внешним маршрутам и решениям allow или allow_after_redaction.

Затем он группирует результаты по request_id, разворачивает попытки по sequence_no и проверяет четыре связи: действующий в тот момент владелец ключа, версия политики, фактический провайдер и источник решения доступа. Запрос к хранилищу может выглядеть так:

SELECT request_id, actor_id, key_id, policy_version,
       provider_id, processing_region, decision, reason_code
FROM audit_events
WHERE tenant_id = :tenant
  AND received_at >= :from_utc
  AND received_at < :to_utc
  AND pii_types @> ARRAY['iin']
ORDER BY request_id, sequence_no;

Результат сузит круг событий, но без отпечатка или защищенного тела не установит, в каком из них был конкретный ИИН. В отчете надо честно разделить подтвержденное, вероятное и неизвестное. Подтверждено, например, что три вызова нашли ИИН и один ушел внешнему провайдеру в режиме monitor. Вероятно, утечка связана с этим вызовом. Точное содержимое остается неизвестным.

Во время одной такой репетиции обычно всплывает неприятная дыра: событие разрешения есть, а запись маршрута потерялась при повторной попытке; версия политики ссылается на конфигурацию, которую уже перезаписали; часы одного сервиса отстают; удаленный ключ больше нельзя связать с владельцем. Это дешевле обнаружить на учебном наборе, чем объяснять после реального инцидента.

Репетиция должна завершаться не презентацией, а таблицей доказуемости. Для каждого вопроса укажите поле, систему-источник, срок хранения, роль с доступом и ожидаемый пробел. Если вопрос «какое точное значение ушло» помечен как недоказуемый, руководство может осознанно принять риск или одобрить контур отпечатков. Плохой вариант только один: узнать об этой границе после утечки.

Сохраняйте тела запросов лишь там, где конкретное обязательство требует реконструкции и где команда способна защитить весь жизненный цикл этой копии. Для большинства расследований лучше подробные метаданные, неизменяемые версии политик и контролируемые HMAC-отпечатки. Такой журнал не знает лишнего, но на вопросы о пользователе, ключе, проверке, маршруте, времени и решении отвечает без догадок.