Чувствительные данные в отчётах о сбоях: остановите утечки контекста агента

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

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

Отчёт о сбое - это пакет свидетельств, а не просто стек вызовов

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

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

Отчёт может раскрыть данные через:

• сообщения исключений, в которые подставлены URL, команда или тело ответа;
• хлебные крошки из журналов запросов или событий вызова инструментов;
• пользовательские поля, в которые передаётся целый объект запроса;
• аргументы командной строки, пути к временным файлам и значения, полученные из окружения;
• прикреплённые файлы, снимки экрана, запись сеанса или отзывы в службу поддержки.

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

В документации Apple диагностические отчёты описываются как записи для поиска причин проблем приложения, содержащие сведения о процессах и потоках. Это полезный набор данных, обычно более узкий, чем событие мониторинга приложения. Но когда SDK обогащает отчёт вашим собственным контекстом выполнения, граница данных меняется. Считайте такое обогащённое событие данными приложения, которые направляются в другую систему.

Сбои агентов создают особенно подробный диагностический контекст

Обычный обработчик запроса может завершиться ошибкой, указав маршрут и код состояния. Действие агента может содержать инструкцию пользователя, пути к репозиторию, вывод команды, аргументы удалённого API, SSH-адрес и предыдущие результаты инструментов, которые привели к сбою. Этот контекст помогает воспроизвести проблему. Но неосторожный сбор делает утечку гораздо опаснее.

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

Та же ошибка возникает при таком коде:

try {
  await runTool(toolName, input);
} catch (error) {
  throw new Error(`Tool failed: ${toolName} input=${JSON.stringify(input)} error=${error.message}`);
}

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

try {
  await runTool(toolName, input);
} catch (error) {
  throw new Error(`Tool failed: name=${toolName} request_id=${requestId} input_shape=${inputShape}`);
}

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

Исходный запрос не должен собираться по умолчанию

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

Безопасному событию достаточно фактов для группировки, первичной оценки и маршрутизации инцидента:

{
  "request_id": "rq_8c2f1a",
  "channel": "http",
  "method": "POST",
  "route": "/v1/issues/{issue_id}/comments",
  "status_class": "5xx",
  "duration_ms": 8120,
  "attempt": 2,
  "error_kind": "upstream_timeout"
}

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

Не хешируйте секреты, выдавая результат за удалённые данные. Детерминированный хеш по-прежнему может связывать повторяющийся токен Bearer и уязвим, если исходное значение выбирается из небольшого пространства вариантов. Заменяйте чувствительные значения постоянным маркером или удаляйте их. Если нужно знать, были ли учётные данные в запросе, запишите auth_present: true, но не их тип, длину, начало или отпечаток.

Проверьте и работу с URL. Многие библиотеки автоматически записывают полные URL. Маршрут вроде /callback?code=... или подписанный URL для скачивания может просочиться через поле, которое разработчик вручную не добавлял. Удаляйте строки запроса до того, как событие попадёт в SDK, а не надейтесь, что последующий обработчик распознает все варианты.

Очистка должна выполняться до хранения и экспорта

Очистка - это последняя линия защиты, а не разрешение собирать всё подряд. Хуки SDK работают по-разному: одни обрабатывают итоговое событие, другие только выбранные поля, а некоторые не охватывают вложения нативных отчётов о сбоях или хлебные крошки, созданные отдельной интеграцией. Правило для Authorization может пропустить authorization, x-api-token, параметр URL или строку JSON внутри исключения.

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

Эта последовательность в псевдокоде предотвращает большинство проблем:

request arrives
  -\u003e derive route template and request ID
  -\u003e retain protected local diagnostic record if policy permits
  -\u003e create minimal crash context from allowlisted fields
  -\u003e scrub all residual strings
  -\u003e send minimized event

Не передавайте исходный объект запроса в callback «перед отправкой». После того как библиотека изучила этот объект, плагины могли уже превратить его в хлебные крошки или spans. Передавайте коду телеметрии небольшой объект, который изначально не может содержать чувствительные поля.

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

Настройки SDK меняются вместе с интеграциями

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

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

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

В macOS проверяйте и отчёты на уровне приложения, и диагностику операционной системы. Отчёты о сбоях Apple могут оставаться локальными или передаваться согласно настройкам системных отчётов, тогда как сторонние SDK используют собственную конфигурацию и сетевой путь. Настольное приложение должно чётко объяснять эту разницу тем, кто его обслуживает. Фраза «отчёты о сбоях отключены» ничего не значит, если отдельный клиент мониторинга ошибок по-прежнему загружает обогащённые события.

Храните учётные данные за пределами процесса агента

Очистка уменьшает риск после того, как код уже обработал секрет. Более сильный подход - не давать процессу агента доступ к секрету вообще. Тогда после сбоя агента, копирования окружения или случайного отладочного дампа для сбора останется меньше чувствительных данных.

Это не делает отчёт о сбое безвредным. В агенте по-прежнему могут находиться закрытый исходный код, промпты или аргументы инструментов. Но токен Bearer не может утечь из процесса, который никогда его не получал.

Sallyport использует эту границу для HTTP API и SSH-действий: приложение хранит учётные данные в зашифрованном хранилище, выполняет действие и возвращает результат агенту, не передавая ему сами учётные данные. Это устраняет одну распространённую причину утечек через телеметрию сбоев, но всё равно нужно сокращать данные запросов и текст результатов, с которыми работает агент.

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

Для локального хранения тоже нужны правила срока хранения

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

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

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

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

Проверяйте сборщик с помощью заранее добавленных секретов

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

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

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

Запишите ожидаемый результат. Например, отчёт может содержать route=/v1/files/{file_id} и request_id=rq_test_01, но не должен содержать MARKER_HEADER_7, MARKER_PROMPT_7 или буквальную строку запроса. Относитесь к неудачному тесту как к дефекту безопасности: отключите проблемный путь сбора, добавьте регрессионный тест и повторно проверьте сериализованное событие.

Короткая проверка выявляет большинство случайных экспортов

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

Используйте этот короткий список при проверке:

• В сообщениях ошибок есть идентификаторы и категории, но нет сериализованных входных или выходных данных.
• Телеметрия получает контекст из разрешённого списка, а не исходный объект запроса или состояния агента.
• Из URL удаляются строки запроса, а заголовки никогда не попадают в хлебные крошки или пользовательские поля.
• Полная локальная диагностика хранится в защищённом месте, имеет правила удаления и понятную причину существования.
• Тест с заранее добавленными маркерами охватывает каждое настроенное место экспорта.

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