Если Sentry получает персональные данные пользователей, мониторинг превращается в источник риска. В события могут попасть email, телефоны, токены, содержимое форм, адреса и приватные payload.

Нужно определить, какие данные уходят в события, и настроить фильтрацию до отправки, а не только скрывать поля в интерфейсе Sentry.

Коротко: что сделать

  • Посмотреть реальные события Sentry и поля request/user/extra
  • Найти токены, email, телефоны, cookies и payload форм
  • Настроить beforeSend или аналогичный hook
  • Добавить server-side scrubbers и denylist
  • Проверить логи после тестовой ошибки

Основные причины

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

  • В Sentry отправляется полный request body
  • В extra/context добавляют объект пользователя целиком
  • Не настроена фильтрация cookies и headers
  • Frontend отправляет state приложения с персональными полями
  • Логи ошибок содержат секреты и токены

Пошаговая диагностика

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

  • Открыть несколько последних events и проверить вкладки request/user/breadcrumbs
  • Создать тестовую ошибку с контрольным email
  • Проверить SDK config на frontend и backend
  • Проверить integrations, breadcrumbs и captureMessage
  • Проверить правила data scrubbing в проекте

Как исправить проблему

Исправление должно закрывать первопричину. Если затронуты платежи, доступы, персональные данные, уведомления или рабочие заказы, сначала проверьте решение на тестовом сценарии и сохраните возможность отката.

  • Удалять PII в beforeSend до отправки
  • Передавать user.id вместо email и телефона
  • Обрезать request body для приватных endpoint
  • Фильтровать Authorization, Cookie и Set-Cookie
  • Добавить список запрещенных ключей для forms и payload

Безопасный план решения

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

Чего не стоит делать

  • Не отправлять полный объект пользователя в context
  • Не логировать токены, пароли и cookies
  • Не считать UI-маскирование достаточной защитой
  • Не хранить события дольше, чем нужно для диагностики

Что подготовить перед исправлением

  • Проект Sentry и SDK
  • Примеры событий с лишними данными
  • Список чувствительных полей
  • Где стоит frontend и backend SDK
  • Политика хранения логов

FAQ

Можно ли оставить email пользователя в Sentry?

Лучше использовать внутренний user_id. Email является персональными данными и часто не нужен для диагностики.

Где фильтровать данные?

На стороне приложения до отправки события, плюс дополнительными правилами scrubbing в Sentry.

Что делать со старыми событиями?

Зависит от требований: удалить, сократить срок хранения или очистить проект, если туда попало много чувствительных данных.

Когда стоит обратиться за помощью

Обращаться стоит, если в Sentry уже попали персональные данные, платежные payload или токены, и нужно быстро закрыть риск.

Итог

Проверьте events, настройте beforeSend, scrubbers и фильтрацию headers/body. Если нужно привести Sentry к безопасной схеме логирования, пишите в Telegram @rabotator_support.