РУКОВОДСТВО · ОБНОВЛЕНО 2026-11-01
Логи LLM без секретов: что сохранять вместо полного промпта
Политика журналирования на всех участках, где могут оказаться запрос, ответ и исключение.
Для разбора большинства технических сбоев не требуется сохранять полный промпт и ответ. Начните с разрешённого набора полей: идентификатор, время, маршрут, статус, длительность и безопасные счётчики. Маскирование должно действовать до записи в журнал и до отправки в систему наблюдаемости. Проверьте также исключения SDK, трассировки и прокси: секрет может попасть в них независимо от основного логгера. Минимизация журналов не гарантирует анонимность сама по себе; доступ, сроки хранения и возможность удаления нужно определить отдельно для вашего процесса.
1. Опишите диагностическую задачу
Для каждого события запишите, зачем поле нужно и кто его читает. Отделите эксплуатационные метрики от специально разрешённого разбора содержимого. Не включайте полный текст по умолчанию только потому, что это удобно при разработке. OWASP рекомендует исключать секреты и чувствительные данные из обычных журналов. Идентификатор пользователя тоже может быть чувствительным в сочетании с другими полями, поэтому список разрешённых значений должен соответствовать реальной задаче, а не только маске имени или телефона.
2. Проверьте все точки записи
Проследите путь запроса через приложение, SDK, reverse proxy, очередь, трассировку и внешние приёмники. Исключение может содержать сериализованный запрос или заголовок авторизации. Не передавайте объект ошибки в лог целиком без контроля. Формируйте безопасное представление с категорией и необходимыми полями. Если один экспорт очищен, а другой получает исходный span, защита неполна. Проверяйте вложенные структуры и вложения, а не только верхнюю строку сообщения пользователя.
3. Минимизируйте и контролируйте доступ
Не храните данные, которые не нужны для выбранной диагностики. Для разрешённых журналов определите круг доступа, срок хранения и процедуру удаления в каждой копии. Хеш короткого известного значения не делает его автоматически анонимным: некоторые значения можно перебрать или связать с другими событиями. Не переносите юридические обещания об обезличивании из рекламного текста в технический отчёт без отдельной проверки. Защита логов и политика отправки данных модели — связанные, но разные границы.
4. Проверьте журнал синтетическими маркерами
Создайте безопасные тестовые строки, похожие на секрет и персональные поля, и проведите их через успешный запрос, ошибку валидации, сетевой сбой и повтор. Ищите маркеры в локальных логах и во всех разрешённых экспортируемых представлениях. Не используйте настоящий API-ключ ради проверки маски. Убедитесь, что после очистки остаётся достаточно сведений для сопоставления событий и поиска причины ошибки. Отдельно проверьте удаление и истечение срока, а не только красивый вид одного сообщения в консоли.
Частые вопросы
Достаточно ли скрыть Authorization в HTTP-логах?
Нет. Тело документа, ответ, исключение и трассировка могут попасть в другие журналы. Нужна проверка всех точек записи и экспорта.
Можно ли включить полный промпт только при ошибке?
Именно ошибка часто содержит чувствительные данные. Такой режим требует отдельного разрешённого процесса, ограничения доступа и срока, а не автоматического включения.
Делает ли хеш пользователя журнал анонимным?
Не автоматически. Связываемость событий и возможность перебора зависят от данных и схемы. Оцените риск и минимизируйте сохраняемое.
Нужно ли вызывать настоящую модель для теста маскирования?
Нет. Локальные фикстуры с синтетическими маркерами позволяют проверить обработчики и экспорт без раскрытия реальных данных и платной генерации.