PII-редакция и log injection

Команда завершает SOC 2 аудит. Аудитор находит сырые email-адреса и auth-токены в трёх месяцах indexed-log-хранения. Логи никогда не числились как data store. Remediation занимает шесть недель и обходится дороже, чем изначальная logging-инфраструктура.

Почему логи — PII-риск

Логи генерируются в hot-path каждого запроса. Они накапливают request body’и, headers, database-запросы, stack trace’ы — любой из них может нести чувствительные данные, если инженер не был аккуратен.

Типичные PII-паттерны из реальных инцидентов: полные request body’и включая Authorization-заголовки и session-токены, email-адреса, залогированные как контекст userId, телефонные номера в user-submitted-полях форм, сырые SQL-запросы с пользовательским вводом, stack trace’ы с object-dump’ами, включающими записи клиентов.

Проблема накапливается: логи хранятся неделями или месяцами, реплицируются в cold storage и читаемы значительно более широкой аудиторией, чем primary-БД. Утечка log-backend’а открывает данные, которые никогда не должны были там находиться.

Редакция в источнике

Logger SDK — правильная первая линия защиты. Каждый крупный продакшн-logger поддерживает deny-list, убирающий известные sensitive-пути до сериализации:

• pino (Node.js): опция redact принимает массив dot-notation-путей (['req.headers.authorization', 'body.password', 'user.email']). Pino заменяет значения на [Redacted] перед записью. Overhead: примерно 2 мс на 1000 сообщений для 5 полей.
• log4j2 (JVM): pattern-converter’ы и Rewrite-appender’ы могут убирать поля по имени ключа.
• structlog (Python): processor в цепочке processor’ов может убирать или хешировать sensitive-ключи до рендеринга.
• slog (Go): custom Handler оборачивает base handler и фильтрует атрибуты до записи.

Статическая редакция (известные пути полей) дёшева. Динамическая редакция (regex по всему message body) в 4-10 раз дороже и должна использоваться только для неструктурированных полей, где невозможно заранее перечислить пути.

Defence in depth: tier collector’а

Application-level редакция ловит намеренные пути. Tier collector’а ловит то, что приложение пропускает — сторонние библиотеки, логирующие request-объекты, ошибки, сериализующие неожиданный контекст, или новый сервис, ещё не принявший per-org wrapper-logger.

OTel Collector, Fluent Bit и Vector поддерживают redaction-processor’ы, прогоняющие regex-паттерны по атрибутам log-записи до отправки. Паттерн: убирать известные PII-форматы (email-адреса, шаблоны телефонных номеров, последовательности похожие на credit-card) в каждой строке независимо от имени поля. Это добавляет latency в collector-pipeline (20-50 мкс на строку для набора из 5 паттернов), но работает вне critical application-path и стоит своей цены.

Продакшн-правило: deny-list в источнике для известных полей; regex scrubber на collector’е как safety net. Никогда не полагайся на собственное маскирование log-backend’а как на первый или единственный слой — к тому времени данные уже покинули хост.

Log injection: security failure-mode

Log injection (CWE-117) происходит, когда пользовательский ввод конкатенируется или интерполируется в log-message без санитизации. Две формы атаки:

Newline injection: ввод содержит литеральный newline. Log-строка вроде INFO: received comment: <user input> разделяется на две строки, когда ввод содержит newline с последующим сформированным payload — ERROR: admin user X deleted production database. Downstream-парсеры, SIEM-rules и audit-trail consumers трактуют обе строки как реальные записи. Манипуляция audit-trail — учебниковый сценарий.

JSON structural injection: в JSON-выводе, если пользовательский ввод конкатенируется в string-поле без escaping — а не передаётся как value JSON-сериализатору — special-characters могут закрыть текущую строку и инжектировать новые key-value-пары, портя log-запись и потенциально обходя SIEM-фильтры, полагающиеся на конкретные значения полей.

Уязвимость Log4Shell (CVE-2021-44228, декабрь 2021) была родственным, но отдельным fail: feature message lookup log4j2 обрабатывал log-message-контент как шаблон, позволяя JNDI-lookup’ам в user-controlled строках триггерить remote code execution. Урок обобщается: log-message-контент — input surface.

Предотвращение структурное: никогда не интерполируй пользовательский ввод в log-message-строки. Всегда передавай пользовательский ввод как типизированный атрибут-field, позволяя JSON-сериализатору обрабатывать escaping:

// Уязвимо — user input в message-строке
logger.info(`received comment: ${req.body.comment}`);

// Безопасно — user input как типизированное поле
logger.info({ event: "comment_received", comment: req.body.comment }, "comment received");

Сериализатор escape’ит значение поля, делая инъекцию структурно невозможной независимо от содержимого ввода.