Перейти к основному содержимому
Возможность

Маскирование конфиденциальных данных

Маскируйте конфиденциальные данные до того, как они достигнут пользователя и логов, — а не после того, как они покинут бэкенд.

TR7 Маскирование конфиденциальных данных не оставляет риск утечки данных только на усмотрение кода приложения. Оно обеспечивает раздельные уровни защиты в теле ответа, в полях логов и в значениях cookie, снижая вероятность неконтролируемого попадания конфиденциальной информации к пользователям, в браузеры или системы логирования. Для маскирования тела ответа данные могут быть замаскированы, полностью заменены или дополнены HTML-тегом на основе совпадения по regex или строке. Операторские паттерны охватывают номера карт, идентификационные номера, email-адреса, номера телефонов и любые специфические для организации форматы конфиденциальных данных. На стороне логов маскирование IP, а на стороне cookie — шифрование на основе AES-256-GCM работают как независимые уровни защиты. В результате не только ответ, но и данные сессии, и процессы хранения логов становятся более контролируемыми с точки зрения утечки данных. Результат: TR7 обрабатывает конфиденциальные данные не в единой точке, а в теле ответа, в логах и в слоях cookie совместно, превращая предотвращение утечки данных в платформенную политику, независимую от кода приложения.

3
Стратегии маскирования: символ маски, полная замена, вставка HTML-тега
3
Уровни утечки данных: тело ответа, IP в логах, шифрование cookie
5
Параметры маски: символ, смещение, мин. вхождения, исключённые символы, чувствительность к регистру

Когда конфиденциальные данные не замечены в коде приложения, утечка уже достигла экрана пользователя и системы логирования.

Маскирование конфиденциальных данных в большинстве организаций оставляется на усмотрение команд разработки приложений. Однако в современных архитектурах одновременно работают десятки микросервисов, разные команды, разные циклы выпусков и устаревшие приложения. Номер карты, поле идентификатора, список email-адресов или токен сессии, забытый в одном сервисе, может оказаться в производственном ответе или в логах.

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

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

Правильный подход — превратить защиту конфиденциальных данных в политику на уровне edge, не зависящую от кода приложения. Тело ответа, IP-информация в логах и содержимое cookie должны обрабатываться отдельно с гибкими средствами управления маскированием, такими как regex, точное совпадение, символ маскирования, смещение и минимальное количество вхождений.

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

Наш подход

TR7 применяет защиту конфиденциальных данных через маскирование тела ответа, анонимизацию IP в логах, шифрование cookie и сигналы обнаружения совместно.

Маскирование тела ответа применяется до того, как данные покидают edge

TR7 может маскировать или заменять конфиденциальные поля в теле ответа с помощью строкового или regex-совпадения. Бэкенд-сервис остаётся неизменным, тогда как контент, возвращаемый пользователю, контролируется на уровне edge.

Маскирование IP на уровне логов снижает риск раскрытия записей

Правило ipMask обеспечивает маскирование IP-информации клиента в логах. Этот подход помогает снизить видимость персональных данных в процессах хранения данных и обеспечения соответствия требованиям.

Шифрование cookie защищает данные сессии на стороне клиента

Правило cookieEncryption может шифровать выбранные значения cookie с помощью AES-256-GCM. Содержимое cookie становится нечитаемым на стороне пользователя, тогда как платформа может управлять этими значениями там, где это необходимо в потоке запросов.

Обнаружение конфиденциальных данных создаёт сигналы атак и утечек

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

Возможности

Маскирование конфиденциальных данных реализует различные стратегии защиты данных в теле ответа, логах и слоях cookie совместно.

Правило modifyResponse маскирует и заменяет содержимое тела ответа

Правило modifyResponse работает на этапе ответа и может обрабатывать совпадающие данные в теле ответа. Значение modifyType может быть задано как mask, replace или htmlTag. Режим mask скрывает символы, режим replace заменяет всё значение, а режим htmlTag добавляет контролируемый HTML или скрипт в ответ. Эта гибкость охватывает не только скрытие данных, но и сценарии, требующие преобразования ответа.

Совпадение по regex и строке поддерживает операторские паттерны конфиденциальных данных

TR7 может выполнять совпадение с использованием буквальной строки или regex через поля matcher и matcherType. Операторы могут определять собственные паттерны для национальных идентификационных номеров, IBAN, номеров карт, номеров телефонов, email-адресов или специфических для организации форматов данных. Готового каталога PII нет; управление зависит от паттерна, определённого оператором. Этот подход с одинаковой гибкостью поддерживает различные форматы стран и отраслей.

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

maskChar позволяет выбрать символ маскирования и проверяется как одиночный символ. maskOffset контролирует, сколько символов остаётся видимым с начала или конца; при значении 0 маскируется всё совпадение. maskFrom предотвращает применение маскирования до достижения минимального количества вхождений. Эти настройки делают как пользовательский опыт, так и риск ложноположительных результатов более управляемыми.

Частичное маскирование поддерживает соответствующие сценарии, такие как отображение последних четырёх цифр

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

Режим replace полностью заменяет конфиденциальное значение безопасным текстом

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

Маскирование тела может работать с потоковыми и chunked-ответами

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

Ограничение размера тела ответа обеспечивает контролируемое управление производительностью

Маскирование тела ответа может планироваться в рамках стандартного ограничения в 16 КБ. При необходимости ограничение может быть увеличено через интерфейс, однако решения о маскировании при размерах в сотни мегабайт должны сопоставляться с влиянием на производительность. Это ограничение помогает балансировать защиту данных на уровне edge с производительностью трафика. Операторы намеренно задают область на критических сервисах.

Шифрование cookie защищает выбранные значения cookie с помощью AES-256-GCM

Правило cookieEncryption используется для предотвращения читаемости содержимого cookie на стороне клиента. Выбранные значения cookie могут шифроваться с помощью AES-256-GCM. Правило предназначено для однократного использования на пул, чтобы предотвратить повторные конфликты. Данные сессии или sticky cookie, таким образом, становятся невидимыми для пользователя как значимый контент.

Маскирование IP в логах анонимизирует IP-информацию клиента на уровне записи

Правило ipMask помогает маскировать IP-информацию клиента в полях логов. Эта функция снижает риск хранения логов в средах с требованиями к защите данных, аналогичными GDPR или местным нормативным актам о конфиденциальности. Видимость персональных данных на стороне записи может быть ограничена, пока трафик приложений продолжает работать. Команды по безопасности и соответствию совместно управляют уровнем детализации логов и требованиями к конфиденциальности.

Обнаружение тестовых номеров карт создаёт сигнал утечки и изоляции тестовой среды

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

Операционная глубина

Маскирование конфиденциальных данных эксплуатируется совместно с поведением фильтрации ответа, обработкой regex, параметрами маскирования, шифрованием cookie, маскированием IP и ограничениями тела.

01

Поведение фильтра ответа

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

02

Режим regex и строки

Когда matcherType задан как regex, используется совпадение на основе паттерна; при задании как string применяется буквальное совпадение. Правила regex мощны, но должны быть написаны тщательно. Слишком широкие или затратные паттерны могут создавать риск производительности и ложноположительных результатов.

03

Проверка символа маскирования

maskChar проверяется как одиночный символ. Значение по умолчанию — звёздочка. Требование одиночного символа помогает сохранить предсказуемость и согласованность вывода маскирования.

04

Управление смещением и количеством вхождений

При maskOffset равном 0 всё совпадение может быть замаскировано; при более высоких значениях заданное количество символов может оставаться видимым. Значение maskFrom устанавливает минимальное количество вхождений перед применением маскирования. Эти настройки особенно важны для балансировки снижения ложноположительных результатов и читаемости.

05

Раздельные линии защиты

cookieEncryption, ipMask и modifyResponse — не варианты одного конвейера; они работают как разные типы правил. Тело ответа, логи и слой cookie каждый защищается с отдельным поведением. Это разделение позволяет выбирать подходящее средство управления для каждого канала утечки данных.

06

Планирование ограничения тела

Маскирование тела ответа оценивается в рамках ограничений буфера. Стандартное ограничение в 16 КБ достаточно для многих API-ответов; более крупные ответы могут быть поддержаны путём увеличения ограничения через интерфейс. Влияние на производительность и использование памяти при больших значениях должны планироваться отдельно.

Когда это использовать

Маскирование номеров карт в ответах банковского API

Банковские команды могут фиксировать значения, похожие на номера карт, с помощью regex и маскировать их так, чтобы были видны только последние четыре цифры. Тело ответа защищается на уровне edge без изменения бэкенд-сервиса.

Полное скрытие идентификационных данных на медицинском портале

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

Анонимизация IP-информации клиента в логах

Команды по соответствию могут использовать ipMask для маскирования IP-информации клиента в логах. Это снижает видимость персональных данных при хранении логов, сохраняя при этом операционный поток записей.

Обеспечение нечитаемости сессионных cookie на стороне клиента

E-commerce и финансовые сервисы могут использовать cookieEncryption для шифрования выбранных значений сессионных или sticky cookie. Содержимое cookie становится невидимым как значимые данные на стороне пользователя, снижая риск подделки.

Часто задаваемые вопросы

Для каких типов данных можно использовать маскирование тела ответа?
Маскироваться может любой формат данных, определённый совпадением по regex или буквальной строке. Операторы пишут собственные паттерны для номеров карт, национальных идентификационных номеров, IBAN, email-адресов, номеров телефонов или специфических для организации полей. Готового каталога PII нет; область маскирования зависит от паттерна, определённого оператором.
В чём разница между режимом mask и режимом replace?
В режиме mask совпадающие символы скрываются выбранным maskChar, а maskOffset позволяет начальным или конечным символам оставаться видимыми. В режиме replace совпадающее значение полностью заменяется настроенным текстом. Операторы могут выбирать между этими двумя стратегиями независимо для каждого правила.
Работают ли cookieEncryption и modifyResponse в одном конвейере?
Нет. cookieEncryption, ipMask и modifyResponse — разные типы правил и работают в отдельных конвейерах. Тело ответа, IP в логах и слой cookie каждый защищается независимым поведением. Подходящий тип правила выбирается отдельно для каждого канала.
Как следует планировать маскирование для больших тел ответа?
Стандартное ограничение буфера тела составляет 16 КБ и может быть увеличено через интерфейс. Однако для очень больших ответов необходимо оценивать влияние буфера маскирования на память и задержку. На критических сервисах область и ограничения размера задаются намеренно.
Маскирование IP влияет только на логи?
Да. Правило ipMask маскирует IP-информацию клиента в полях логов. Трафик приложений и решения о маршрутизации не затрагиваются; снижается только видимость персональных данных на стороне записи.
Что делает параметр maskFrom?
maskFrom определяет, сколько раз должно произойти совпадение, прежде чем применяется маскирование. Например, при maskFrom равном 2 маскирование не применяется при единственном вхождении; правило активируется только тогда, когда то же значение появляется как минимум дважды. Этот параметр используется специально для снижения риска ложноположительных результатов.

Защищайте конфиденциальные данные на уровне платформы

Предотвращение утечки данных в теле ответа, логах и слоях cookie. Давайте пройдём живую настройку на ваших собственных сервисах.