Обработка PII

Что считаем PII

• ФИО

• Emai

• Телефон

• IP-адреса конечных пользователей (не внутренние сервисные)

• UserID/AccountID → технически идентификатор, но он тоже PII, т.к. может связать запись с конкретным человеком

• Данные платёжных инструментов (карта, счёт, IBAN и т.п.) — строго нельзя логировать

Базовый принцип

Лог ≠ источник бизнес-данных.

В логах должно быть ровно столько данных, сколько нужно для диагностики, а не больше.

Правила

Что нельзя логировать

• Полные ФИО

• Email и телефон (если очень надо — хэшировать)

• Полные номера карт, счетов

• Адреса (почтовые)

Что можно логировать в обезличенном виде

• UserID → UUID или внутренний ID можно, но:

  • лучше заменить на hash(user_id) с солью, если нужен поиск по пользователю

  • или использовать внутренний surrogate ID, не совпадающий с PK в БД

• IP-адрес

  • внутренние служебные (10., 192.168., 172.16.*) можно логировать полностью

  • внешние → хранить в обрезанном виде, например, 192.0.2.xxx, или хэшировать

• Email, телефон → либо вообще не логировать, либо заменять на hash(email) (для отладки дублей)

Маскирование

• Если PII всё же проходит в логи, например, exception stacktrace → Fluent Bit/OTel Collector должен маскировать

• Пример: user.email = "[e-mail]" → user.email = "***@example.com"

• Для телефонов: [phone] → +7 *** ***-**-67

Где применять маскирование

• На стороне приложения (.NET, IIS, Nginx)

  • Лучше всего: не писать PII в лог вовсе

  • Использовать structured logging: пишем UserId=12345, а не email=[e-mail]

• На стороне агента (Fluent Bit/OTel)

  • Если невозможно гарантировать на уровне кода — ставим фильтры:

    • Fluent Bit: Filter modify или Lua-фильтр → regexp для email/телефонов

    • OTel Collector: transform processor для маскировки

• На стороне хранилища (VictoriaLogs)

  • Лучше PII сюда не допускать. VictoriaLogs не изменяет данные — только хранит.

Retention и доступ

• Retention для логов с потенциальным PII → короче (например, 14–30 дней)

• Доступ в Grafana/VictoriaLogs UI: только через SSO + RBAC

• Запрещён общий доступ к сырым логам (CSV/JSON-экспорт) без обоснования

Документация и политика

• Завести документ «Политика логирования» (внутренний регламент)

• Чётко прописать:

  • разрешённые поля (service, env, level, message, trace_id, …)

  • запрещённые поля (PII/финансовые)

  • Ответственность: разработчик → ревью кода → контроль на CI