# Open WebUI: как включить журнал аудита и проверить события

Источник: https://modelium.tech/zhurnal/open-webui-audit-log/

В Open WebUI аудит API-запросов по умолчанию выключен: для осторожного старта задайте `AUDIT_LOG_LEVEL=METADATA`, настройте вывод и проверьте запись тестовыми учётными записями. По умолчанию чтение GET и часть маршрутов чатов не попадают в журнал, а метаданные могут содержать полный URL. Такой лог не заменяет события провайдера SSO и проверку прав на документы внутри RAG.

**Документы просмотрены 26 сентября 2026 года.** Это инструкция по настройке и *план проверки*, не протокол испытаний Modelium. Сверьте имена переменных и маршруты с закреплённой версией вашего Open WebUI. Частотность запроса не измерялась.

## Что именно журналирует Open WebUI?

В Open WebUI `AUDIT_LOG_LEVEL` по умолчанию равен `NONE`. Уровень `METADATA` добавляет запись об API-вызове: пользователь, если его удалось определить, IP, user agent, метод, URL и время; в закреплённой редакции кода есть также код ответа [s1](#src-s1)[s6](#src-s6). `REQUEST` дополняет запись телом запроса, `REQUEST_RESPONSE` — телами запроса и ответа [s1](#src-s1). Это **журнал API-активности**, а не автоматически полный журнал выполнения агентных инструментов, фактических обращений к каждому документу, операций провайдера модели и событий внешнего провайдера идентификации. Полноту нужно проверять для конкретной версии и топологии установки.

Обычные серверные логи — другая поверхность. `GLOBAL_LOG_LEVEL` и `LOG_FORMAT=json` управляют выводом backend в stdout; форматирование JSON само по себе не включает audit log [s3](#src-s3). Если чат содержит персональные или коммерческие сведения, начните с `METADATA`: документация Open WebUI отдельно предупреждает, что уровни с телами запросов/ответов требуют согласования платформы хранения содержимого чатов [s4](#src-s4). Даже метаданные не автоматически обезличены: код записывает URI как строку URL; не помещайте секреты или текст запроса в query-параметры и проверьте фактический формат события до пересылки в SIEM [s6](#src-s6).

## Как включить запись без содержимого переписки?

Укажите переменные окружения *вашего уже установленного экземпляра* в конфигурации контейнера или сервиса, затем перезапустите его штатным способом. Пример для тестового контура:

AUDIT_LOG_LEVEL=METADATAENABLE_AUDIT_LOGS_FILE=trueAUDIT_LOGS_FILE_PATH=/app/backend/data/audit.logENABLE_AUDIT_STDOUT=true

`AUDIT_LOGS_FILE_PATH` в примере соответствует типичному Docker data-каталогу из руководства hardening; в другой установке каталог может отличаться. По справочнику переменных file-output по умолчанию включён, путь `${DATA_DIR}/audit.log`, stdout-аудит по умолчанию выключен, размер ротации файла по умолчанию `10MB` [s1](#src-s1)[s2](#src-s2). В production выберите **один или осознанно два** канала доставки и проверьте права чтения файла/сборщика stdout: два канала способны дублировать события в SIEM. Запись в файл контейнера без сохранённого volume не равна долговременному хранению. Выбор срока хранения, шифрования резервных копий, ответственного оператора и доступа к архиву — задача организации, а не эффект переключателя `AUDIT_LOG_LEVEL`; рекомендации по защите журнала даёт OWASP [s7](#src-s7).

Для stdout можно установить `LOG_FORMAT=json`, но проверяйте фактический формат именно audit-событий и парсинг на вашем коллекторе: этот флаг отвечает за формат backend stdout, а `ENABLE_AUDIT_STDOUT` — за включение аудит-сообщений туда [s2](#src-s2)[s3](#src-s3). Не отправляйте в отчёт или публичный тикет сырой лог с именами, email, IP и URI.

## Почему в журнале нет чтения документа или части чатов?

По умолчанию middleware аудита обрабатывает `POST`, `PUT`, `PATCH`, `DELETE`, **не GET**; `ENABLE_AUDIT_GET_REQUESTS=true` добавляет GET и резко увеличивает поток событий [s2](#src-s2)[s6](#src-s6). Встроенный список `AUDIT_EXCLUDED_PATHS=/chats,/chat,/folders` исключает соответствующие пути даже при включённом GET. `AUDIT_INCLUDED_PATHS` включает режим allowlist и имеет приоритет над списком исключений; endpoint-ы `signin`, `signout`, `signup` журналируются независимо от обоих списков [s1](#src-s1)[s2](#src-s2). Не объявляйте отсутствие строки в логе доказательством того, что чтения или вызова инструмента не было.

В коде закреплённой ревизии middleware пропускает запросы без заголовка авторизации или cookie токена, кроме перечисленных auth-эндпоинтов [s6](#src-s6). Событие входа через внешний SSO/IdP, обратный прокси или вызов модели может жить в *другой* системе. Для сквозного расследования сопоставляйте журналы IdP, proxy, Open WebUI и runtime по временным меткам, не считая аудит интерфейса единственным источником истины. Оставляйте `REQUEST`/`REQUEST_RESPONSE` выключенными, если не одобрена запись содержимого: реализация маскирует только определённое поле `password` в теле запроса, а не произвольные токены и персональные данные [s1](#src-s1)[s6](#src-s6).

## Как проверить два аккаунта и не принять пустой лог за успех?

Проведите следующий **тестовый протокол** на своём контуре и с вымышленными данными; результаты ниже не получены Modelium:

- Создайте две обычные учётные записи A и B и назначьте им различающиеся группы/ресурсы. Администратор может предварительно посмотреть эффективные гранты в `Preview Access` — это *read-only* представление грантов, не доказательство контроля каждого документа внутри общей Knowledge Base [s5](#src-s5). Для настройки входа и ролей откройте [отдельный гайд LDAP/SSO](/zhurnal/open-webui-ldap-sso/).

- Зафиксируйте время начала пробы, ожидаемые операции и идентификаторы тестовых ролей. Выполните вход A и B, разрешённое изменение тестового ресурса под A и попытку того же под B; используйте только безопасный тестовый ресурс, права на который можете откатить. Ожидайте записи с различающимися пользователями, методами, URI и статусами; для неуспешного входа пользователь может быть пустым, а для отдельных запросов запись может отсутствовать из-за фильтра. Проверьте реальный ответ API и состояние ресурса **отдельно** от строки лога [s6](#src-s6).

- Если цель — контролировать **чтение** через API, в изолированном тесте включите `ENABLE_AUDIT_GET_REQUESTS=true`, повторите разрешённое и запрещённое чтение конкретного ресурса и проверьте объём/содержимое журнала. Отдельно учтите исключённые пути и затем задайте узкую политику включения маршрутов; не обещайте, что GET-аудит фиксирует каждый доступ к содержимому документа в модели [s2](#src-s2).

- Сверьте три объекта: audit-событие, фактический HTTP-ответ и изменение грантов. Под B запрещённый ресурс не должен отдаваться, но даже верный код отказа не доказывает корректность фильтрации фрагментов RAG. Для последнего выполните отдельный [двухролевой тест retrieval и отзыва прав](/zhurnal/korporativnyy-poisk-prava-dostupa/). После проверки удалите синтетические данные и верните временно расширенный аудит GET к согласованной настройке.

**Критерий готовности:** обе тестовые записи различимы, события выбранных API-операций сверяются с реальным ответом и правами, оператор видит куда пишется лог и кто его читает. Если события нет — проверьте `NONE`, вывод в файл/stdout, пути и методы, auth cookie/header, ротацию и часы сервисов по сохранённой ревизии; не заполняйте пробелы догадкой. Это не сертификат соответствия и не обещание полной наблюдаемости.

**Следующий шаг:** [проверьте вход и гранты двух тестовых сотрудников](/zhurnal/open-webui-ldap-sso/), а затем повторите контроль API-событий с заранее выписанными ожиданиями. Реальные корпоративные чаты и документы не используйте, пока логирование и доступ к журналу не прошли вашу внутреннюю проверку.

## Источники

1. [Open WebUI — Hardening, Audit Logging](https://docs.openwebui.com/getting-started/advanced-topics/hardening.md) — получено 2026-09-26
2. [Open WebUI — Environment Variable Configuration, Logging](https://docs.openwebui.com/reference/env-configuration.md) — получено 2026-09-26
3. [Open WebUI — Logging](https://docs.openwebui.com/getting-started/advanced-topics/logging.md) — получено 2026-09-26
4. [Open WebUI — Chat Data Privacy and Encryption](https://docs.openwebui.com/security/chat-data-privacy-and-encryption.md) — получено 2026-09-26
5. [Open WebUI — Groups and Resource Access](https://docs.openwebui.com/features/authentication-access/rbac/groups.md) — получено 2026-09-26
6. [Open WebUI — audit.py, pinned source revision](https://raw.githubusercontent.com/open-webui/open-webui/52cfb02c724a617163403aa83f5674a34aa97d1b/backend/open_webui/utils/audit.py) — получено 2026-09-26
7. [OWASP — Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) — получено 2026-09-26