Анализ трафика, аудит и хранение

Роль: администратор контура. Эти действия выполняются в операторской консоли. В обычном hosted-кабинете доступны собственные ключи и лимиты; изменение политик, режима защиты и маскирования запрашивается у администратора.

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

Разобрать запрос от клиента до результата

1. Сохраните Request ID, время UTC, tenant и метку приложения/модели из клиента; исключите исходные секреты.
2. Откройте Аудит и форензика, выберите tenant и период, найдите Request ID.
3. Прочитайте чувствительность, классы, injection, tier, причину и идентификатор политики/правила. Сравните фактическое действие и назначение с ожидаемой политикой.
4. Откройте контент или доказательства замены, только если они сохранялись и доступны вашей роли. Отсутствие контента не доказывает отсутствие инспекции.
5. Для групповых угроз перейдите в Инциденты / Аналитика инцидентов / Утечки данных / Аналитика политик и вернитесь к связанному аудиту.

Значение полей

Отчёты, фильтры и поток

Период, tenant, действие, класс, политика и app ограничивают выборку. Снимите фильтры для сравнения с общей историей, проверьте UTC. «Откл» / «Нет» автообновления и «Пауза» ленты относятся только к браузеру. «Очистить» сбрасывает видимый буфер; сохранённый аудит остаётся. После разрыва SSE часть событий может не повториться — расследуйте по постоянному журналу. «Нет данных» и HTTP 503 — разные результаты.

Classifier Health зависит от доступного источника истории. Сопоставляйте период, долю отказов/fail-safe и latency с текущим состоянием интеграции. Closed у circuit breaker разрешает попытки; это не означает успех каждого запроса. Разбирайте circuit-open/fail-safe по Request ID.

Проверить доступность инспекции

Classifier Health и процентили показывают состояние анализа, а не только работу HTTP-процесса. Ответ 200 от /healthz может содержать inspection_healthy=false: процесс жив, но готовность инспекции не подтверждена. При таком результате зафиксируйте время UTC и стенд, проверьте состояние classifier и повторите проверку после восстановления зависимости. Не отключайте инспекцию для получения положительного health-статуса.

Администратору on-prem: направьте Kubernetes readinessProbe gateway и classifier на /readyz, а livenessProbe оставьте на /healthz. Неготовый gateway возвращает 503 от readiness и должен быть исключён из готовых endpoints; отказ зависимости не должен сам по себе перезапускать живой gateway. После восстановления classifier готовность возвращается автоматически. Используйте внутренний адрес сервиса: внешний ingress может не публиковать /readyz, и внешний 404 не доказывает отказ classifier.

Положительный readiness подтверждает проверенные зависимости в этот момент. Он не заменяет реальный запрос через настроенного провайдера, проверку полномочий и сохранения аудита. Показатели задержки также оценивайте по этапу каскада и оборудованию; p99 быстрого пути Tier 0/1 не является p99 полного ответа LLM.

Подготовить защищённое объектное хранилище

Для контрольных точек аудита в управляемой установке подготовлен отдельный MinIO в Kubernetes: HTTPS, versioning и COMPLIANCE Object Lock. Staging и production используют отдельные namespace, CA и учётные записи. Хранилище предназначено для подписанных хешей и счётчиков; само его наличие не включает публикацию контрольных точек и не означает, что исходные запросы или резервная копия базы уже помещаются в S3.

Администратору on-prem с правами управления хранилищем:

1. Выделите отдельный bucket с versioning и Object Lock. Проверьте чтение COMPLIANCE-срока конкретной версии и отказ удаления/сокращения срока, включая административную S3-учётную запись. Успешная загрузка с retention-заголовком недостаточна.
2. Выдайте шлюзу только чтение нужного префикса и метаданных блокировки. Отдельному процессу публикации выдайте запись с COMPLIANCE без Delete, bypass и административных прав. Ключ подписи и права изменения базы не передавайте шлюзу.
3. Проверьте цепочку CA и имя HTTPS endpoint. Для частного CA используйте явно смонтированный публичный bundle; не отключайте TLS-проверку. Разрешите только необходимые сетевые соединения.
4. Настройте квоту, контроль свободного места, срока сертификатов и доступности реплик. При остановке или откате сохраните PVC/PV. Размещение внутри того же Kubernetes не защищает от администратора, который может уничтожить нижележащие тома; независимая аварийная копия требует отдельного контура и проверки восстановления.

Рабочий срок шифрованных исходных запросов остаётся отдельным. Не переносите их в неизменяемый bucket с более долгим сроком без согласованного lifecycle. Новый процесс подписания/проверки контрольных точек ниже остаётся кандидатом до отдельного выпуска.

Подтвердить сохранение решения

Кандидат обновления: следующий контракт ещё не выпущен в production. Он публикуется как действующая инструкция только вместе с квалифицированным выпуском шлюза.

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

1. Сохраните Request ID и найдите итог в Аудит и форензика. Для новых записей сохраняются полный вердикт, confidence, escalation path, обнаруженные spans и снимок применённых политик с SHA-256. После обновления страницы карточка использует сохранённый вердикт. В старых записях эти поля могут отсутствовать; их значения не восстанавливаются догадкой.
2. Если получен HTTP 503 с кодом audit_unavailable, обязательное сохранение не подтверждено. Не считайте операцию успешной. Перед повтором проверьте Request ID: при потере подтверждения запись могла сохраниться, а прокси мог уже обратиться к провайдеру.
3. В начатом SSE-потоке отказ финального сохранения возвращается как событие ошибки без успешного [DONE]. Ранее выданные проверенные фрагменты уже могли попасть клиенту. Повторяйте запрос только с учётом возможных повторных действий инструментов.
4. При изменении статуса, назначения или заметки инцидента обновление и запись истории фиксируются вместе. При ошибке перечитайте карточку; сообщение об ошибке не означает принятую смену статуса.

Сохранённый снимок решения и исправная локальная цепочка не подтверждают неизменяемость PostgreSQL, точную версию весов или полноту истории всех реплик. Для заключения специалиста ИБ нужны отдельно проверенные права хранилища, внешние закрепления цепочки и процедура восстановления.

Проверить область и ограничения целостности

Кандидат обновления, ещё не production. Не применяйте эти статусы к работающей версии без проверки номера выпуска.

1. С правом чтения аудита откройте Аудит и форензика → Цепочка. Дождитесь завершения проверки. Общий PostgreSQL-журнал проверяется целиком в согласованном снимке: все новые события, процессы записи и этапы запроса, а также связанные записи и история изменений инцидентов. Это число событий, а не счётчик запросов.
2. Различайте «Цепочка аудита согласована» и полное подтверждение целостности истории. Жёлтая панель означает ограниченный результат. Прочитайте область проверки, число исторических записей вне новой цепочки и ограничения. Проверенные права serving-роли и триггеры не заменяют независимый внешний якорь и защищённый архив.
3. В файловом режиме проверяется локальный сегмент одного процесса. Отсутствующее или пустое постоянное хранилище не даёт положительного статуса. HTTP 409 содержит отрицательный отчёт; 503 означает, что основная история недоступна для проверки. Проверьте хранилище и повторите чтение; не создавайте искусственные события для получения зелёного статуса.
4. Отчёт Соответствие использует результат реальной проверки, а не размер ring buffer. JSON-экспорт сохраняет scope, chain_ok, verified, storage_protected, legacy_entries и limitations. Пока внешние закрепления и полнота старой истории не подтверждены, verified остаётся false.

Значение «Очистка защищённого журнала недоступна» означает, что рабочий процесс не имеет права удалять доказательства без квалифицированного архива. Ранее заданный срок виден, но не исполняется; попытка включить положительный период возвращает 409 archive_required. Не обходите ограничение выдачей DELETE или superuser шлюзу. Шифрованные исходные запросы имеют отдельный срок: после его истечения тело становится недоступно, метаданные и квитанции доступа сохраняются. Архивирование журнала, независимые якоря и восстановление ещё требуют отдельной квалификации.

Внешняя контрольная точка — кандидат

В подготовленном обновлении независимый процесс может закреплять подписанную контрольную точку в версионируемом S3 с COMPLIANCE Object Lock. Шлюз использует только публичные ключи и доступ на чтение. Администратор отдельно задаёт доверенные environment/stream и максимальный возраст; ключ подписи не устанавливается в HTTP-шлюз.

После Аудит и форензика → Цепочка прочитайте строку «Внешняя контрольная точка закрепляет записи по № …; новых записей после неё: …». Вторая величина — ещё не закреплённый хвост журнала. Недоступная, просроченная или несовпадающая настроенная точка даёт отрицательный результат, без перехода к положительной локальной проверке. Специалист ИБ сопоставляет Request ID, номер последовательности и JSON-отчёт; не меняет ключи/stream для устранения ошибки.

Контрольная точка содержит хеши и счётчики, не исходные запросы и не резервную копию. Старые записи фиксируются как наблюдаемый baseline; их подлинность до перехода не устанавливается. Даже совпавшая точка не включает полный статус verified=true: независимое восстановление архива ещё требует проверки. Срок доступности шифрованных исходников не продлевается этим механизмом. Этот раздел остаётся кандидатом до staging-регрессии и согласованного production-выпуска.

Операторский архив — ещё не production-функция. Отдельные команды secure-archive capture, inspect и restore предназначены для администратора хранилища. Для публикации нужны отдельная SELECT-only роль БД, S3 publisher и закрытые ключи; для холодного восстановления — S3 reader, AES key и новая явно отмеченная recovery-БД с независимо сохранёнными SHA-256/версией архива. Не передавайте signing key или publisher в процесс восстановления. Исходные тела сохраняют прежний срок доступности; логическое истечение не подтверждает физическое удаление. На изолированной staging-копии полный цикл и доступ к восстановленному исходному запросу проверены, но расписание, physical cleanup и выпуск ещё не квалифицированы. Системный администратор должен хранить ключи вне исходной БД; MinIO и Secrets в одном Kubernetes не заменяют отдельную аварийную копию.

Хранение, исходный контент и права

Аудит и форензика → Хранение журнала → максимальный возраст → Сохранить. Перечитайте статус. Изменение периода отчёта не изменяет срок хранения.

Увеличить скриншот

1 2 3 4

1. Поиск
2. Хранение журнала
3. Дней / сохранить
4. Фильтр tenant

Инспекция, прокси и анализ ответов

/v1/inspect и пакетная инспекция возвращают решение; приложение обязано исполнить block, замену и reroute. Dry-run не перехватывает трафик другого приложения. Выбирайте point=request для входа, response для ответа модели, tool_output для вывода инструмента; app задаётся через X-IAM-Secure-App. /v1/chat/completions использует настроенный прокси с проверкой запроса и ответа. Streaming анализируется перекрывающимися окнами; уже переданные фрагменты нельзя отозвать задним числом. Вердикт инспектора не означает автоматического буферизования полного ответа.

Подробные настройки · FAQ · Раздел аудита