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

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

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

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

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

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

AUDIT_LOG_LEVEL=METADATA
ENABLE_AUDIT_LOGS_FILE=true
AUDIT_LOGS_FILE_PATH=/app/backend/data/audit.log
ENABLE_AUDIT_STDOUT=true

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

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

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

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

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

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

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

1. Создайте две обычные учётные записи A и B и назначьте им различающиеся группы/ресурсы. Администратор может предварительно посмотреть эффективные гранты в Preview Access — это read-only представление грантов, не доказательство контроля каждого документа внутри общей Knowledge Base s5. Для настройки входа и ролей откройте отдельный гайд LDAP/SSO.
2. Зафиксируйте время начала пробы, ожидаемые операции и идентификаторы тестовых ролей. Выполните вход A и B, разрешённое изменение тестового ресурса под A и попытку того же под B; используйте только безопасный тестовый ресурс, права на который можете откатить. Ожидайте записи с различающимися пользователями, методами, URI и статусами; для неуспешного входа пользователь может быть пустым, а для отдельных запросов запись может отсутствовать из-за фильтра. Проверьте реальный ответ API и состояние ресурса отдельно от строки лога s6.
3. Если цель — контролировать чтение через API, в изолированном тесте включите ENABLE_AUDIT_GET_REQUESTS=true, повторите разрешённое и запрещённое чтение конкретного ресурса и проверьте объём/содержимое журнала. Отдельно учтите исключённые пути и затем задайте узкую политику включения маршрутов; не обещайте, что GET-аудит фиксирует каждый доступ к содержимому документа в модели s2.
4. Сверьте три объекта: audit-событие, фактический HTTP-ответ и изменение грантов. Под B запрещённый ресурс не должен отдаваться, но даже верный код отказа не доказывает корректность фильтрации фрагментов RAG. Для последнего выполните отдельный двухролевой тест retrieval и отзыва прав. После проверки удалите синтетические данные и верните временно расширенный аудит GET к согласованной настройке.

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

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