Что маскирование по правилам скрывает в заявке или чате — и что всё равно остаётся

Вставка — это не одна копия. Это несколько копий, которые уже не забрать

Маскирование часто принимают за вежливость: заменить полный номер звёздочками, чтобы сообщение выглядело аккуратно. Ущерб начинается после вставки. Система заявок хранит тело. Мессенджер хранит сообщение. Мониторинг ошибок снимает стек. Запись сессии пишет поле ввода. Очередь подрядчика выгружает ещё один файл. Поменять несколько символов на своём экране не меняет уже записанные копии. Поздний «почистить заявку» правит только текущую строку. История поиска, почтовые уведомления и нижестоящая аналитика часто держат исходный текст.

Шпаргалка OWASP по журналам формулирует это как инженерное ограничение, а не совет по стилю. Там перечислено, что обычно не следует писать в журнал в открытом виде, а нужно удалить, замаскировать, очистить, захэшировать или зашифровать: чувствительные персональные данные и часть идентификаторов (здоровье, государственные документы), пароли, токены доступа, криптографические ключи и другие главные секреты, банковские счета и данные держателя платёжной карты. Внутри компании заявки и групповые чаты часто играют роль неформального журнала: искать удобно, права слабее, чем у боевой базы, срок хранения длиннее. Вставить слова клиента целиком — значит самим создать запись, которую OWASP как раз не советует оставлять.

HTTPS защищает только передачу от подслушивания. Он не стирает открытый текст, который вы уже отдали следующей системе. В предыдущей заметке то же самое сказано про query: он попадает в историю, Referer и журналы доступа. Номер в абзаце — тот же класс утечки, только носитель не URL, а предложение. Вопрос перед отправкой не «безопасна ли эта система заявок», а «нет ли в этом абзаце поля, которому не следует покидать эту вкладку».

Правила ловят форму и контрольную цифру. Смысл предложения они не читают

Маскирование по правилам — узкая работа. Регулярное выражение находит кандидата. Проверочная функция отбрасывает явные промахи. Список приоритетов разбирает пересечения. Сканер не знает, что «Иван Петров» — человек, а «оставьте у консьержа на Тверской» — адрес. Он знает, похожи ли одиннадцать цифр на мобильный номер материкового Китая, проходит ли восемнадцать цифр проверку гражданского номера, проходит ли шестнадцать цифр алгоритм Луна, которым пользуются карты.

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

Контрольная цифра снижает ложные срабатывания. Она не доказывает, что «этот человек существует». Восемнадцатизначный гражданский номер КНР считает последний знак по GB 11643-1999 / ISO 7064 MOD 11-2: первые 17 цифр умножают на веса 7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2; сумму берут по модулю 11; остаток сопоставляют с таблицей 10X98765432. Остаток 2 даёт X, то есть 10. Прохождение значит «строка похожа на правильно собранный номер». Оно не значит, что в реестре есть такой человек. Карты используют алгоритм Луна из ISO/IEC 7812: справа через одну удваивают цифру, если больше 9 — вычитают 9, принимают номер только если сумма делится на 10. Большинство случайно набранных 16 цифр Луна не проходят. Правило не должно считать их картой.

Шесть типов полей: что правило может назвать и как выглядит маска

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

Телефонное правило должно одновременно ловить «слитные 11 цифр» и запись с пробелами, скобками и дефисами. Номер материкового Китая вида 11 цифр с 1[3-9] — открытая форма диапазона, не внутренняя таблица оператора. Международный номер ловят по привычному виду E.164: начинается с +, дальше 7–15 цифр. Слишком короткая цепочка или кусок внутри более длинного числа должны отбрасываться, иначе номер заказа и трек посылки станут «телефонами».

Для российского номера это важно на практике. Запись +7 999 123-45-67 содержит плюс и разделители — такое правило обычно берёт. Слитные 89991234567 без плюса уже ближе к лотерее: одиннадцать цифр, но не форма 1[3-9] и не десятизначный североамериканский номер. Перед отправкой заявки не надейтесь, что «восьмёрка» сама замаскируется. Если номер важен, поставьте его в E.164 или проверьте результат глазами.

В номере документа, кроме контрольной цифры, у 18-значного гражданского номера КНР требуют ненулевой код адреса, год рождения в XIX или XX веке, допустимые месяц и день. Американский SSN в виде AAA-GG-SSSS официально исключает несколько недействительных зон: 000, 666, начало с 9; группа не может быть 00, серийный номер — 0000. Британский NINO — две буквы, шесть цифр и A–D, с исключением префиксов вроде BG и GB. Эти правила повышают уверенность «похоже на документ», а не доказательство «этот человек существует».

Со стороны карт платёжная отрасль разделяет «сколько цифр можно показать на экране» и «как обрезать при хранении». Совет PCI SSC в пояснении про 8-значный BIN повторяет: при показе основного номера счёта общепринятый верхний предел по брендам по-прежнему первые шесть и последние четыре; если должности достаточно последних четырёх для сверки, она должна видеть только их. Заявка в чат — не эквайринг. По умолчанию оставить только последние четыре надёжнее. Это не заявление о сертификации PCI. Это значит: вставить полные 16 цифр в Telegram уже больше, чем обычно допускают на стороне показа.

Если маска почты закрывает только локальную часть и оставляет домен целиком, получатель всё равно видит «это человек из такой-то компании». Правило для ключей опирается на открытые префиксы: классический персональный токен GitHub — ghp_ плюс 36 знаков, токен с тонкой настройкой — github_pat_; идентификатор ключа доступа AWS IAM часто AKIA плюс 16; боевой ключ Stripe — sk_live_. Префикс существует, чтобы SDK и сканеры его узнавали — поэтому правило его и ловит. Самодельный токен без устойчивого префикса и строка, разрезанная на «g h p подчёркивание…», правило пропустит как обычный текст.

IP ловят по допустимому диапазону десятичной записи с точками (каждый октет 0–255), чтобы не забрать версию 1.2.3. Для демонстрации и канарейки берите зарезервированные документацией сети, не боевые адреса. RFC 5737 оставляет 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24 и прямо говорит, что их не должно быть в публичной маршрутизации. Для почты в примерах — example.com, по зарезервированным доменам RFC 2606, а не по названию реальной компании.

Номер документа и карта могут претендовать на одну и ту же цепочку цифр

Восемнадцатизначный гражданский номер состоит из цифр (последний знак может быть X). Если кто-то скормит чисто цифровой документ правилу карты, Луна иногда сойдётся. Когда оба правила сидят на одном абзаце, нужен приоритет. Иначе одну и ту же цепочку замаскируют дважды — или в неправильную форму.

Устойчивый порядок такой: документ раньше ключей, ключи раньше телефона, телефон раньше почты, почта раньше карты, карта раньше IP. Причины конкретные. Сначала документ, чтобы 18-значный идентификатор не проглотили как карту. Префикс ключа характернее, чем «цифры, похожие на телефон». Телефонное правило не должно ещё раз резать цифры внутри почты. IP — самая широкая сеть, поэтому идёт последней и реже съедает версии или числа с точками в номере заказа. При пересечении оставляют попадание с более высоким приоритетом или более длинное.

Если выключить «Номер документа» и оставить «Банковская карта», должно произойти обратное: эту цепочку цифр можно считать картой. Так и задумано при отладке правила. Это не политика отправки по умолчанию. По умолчанию все шесть типов включены, затем человек смотрит ФИО и адреса, которых правила не трогают.

Звёздочки — не обезличивание и не законченная анонимизация

Федеральный закон № 152-ФЗ «О персональных данных» в статье 3 проводит границу, которую маска из звёздочек не пересекает. Пункт 1 называет персональными данными любую информацию, относящуюся к прямо или косвенно определённому либо определяемому физическому лицу. Пункт 9 определяет обезличивание как действия, после которых без дополнительной информации нельзя установить принадлежность данных конкретному субъекту. Пункт 5 отделяет распространение (неопределённый круг лиц) от предоставления определённому кругу в пункте 6. Вставить заявку в общий чат ближе к предоставлению, а иногда и к более широкому кругу. Закон не называет «звёздочки посередине номера» завершённой мерой.

Умная маска нарочно оставляет хвост для сверки: последние четыре телефона, последние четыре карты, домен почты, префикс ключа. Если в заявке ещё есть ФИО, улица или внутренний номер клиента, этих четырёх цифр часто достаточно, чтобы сдвинуть человека от «определяемый» обратно к «определённый». Это в лучшем случае шаг в сторону обезличивания. Это не обезличивание. Полная маска заменяет попадание тем же числом звёздочек и убирает одну сшивку. Длина, позиция и окружающее предложение остаются. Предложение по-прежнему может звучать «перезвоните владельцу» или «скан паспорта во вложении».

Поэтому «правила прогнали» нельзя писать как «этот абзац можно класть в открытую базу знаний» или «это закрывает требование 152-ФЗ». Страница инструмента не заявляет соответствие 152-ФЗ и не заявляет сертификацию GDPR. Точная фраза такая: известные формы заменили маской; неизвестные формы не трогали; можно ли ещё узнать конкретного человека, вы решаете по контексту.

Что правила не ловят, часто и есть та фраза, из-за которой случится инцидент

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

Третье: секреты без открытого префикса. Строка подключения к базе, трёхчастный JWT, самодельный token=, сессионная cookie из мессенджера или внутренней системы — ничего из этого нет в коротком списке ghp_ / AKIA. Четвёртое: вложения и богатый текст: колонтитул Word, скрытый столбец таблицы, телефон в подписи письма, слой внутри PDF. Правила сканируют только обычный текст, который вы вставили в поле. Пятое: смысловые секреты: неопубликованная сумма договора, описание уязвимости, жалоба словами клиента. Это не форма ПДн. Переслать их всё равно вредно.

В российском обиходе к этому списку добавляются три дыры, которые уже заложены выше и здесь стоят чеклистом. СНИЛС в виде XXX-XXX-XXX XX — одиннадцать цифр со своей контрольной суммой, не SSN и не 18-значный гражданский номер КНР. ИНН из десяти или двенадцати цифр короче диапазона карты 13–19 и чаще всего не проходит правило документа. Серия и номер паспорта без латинских букв выглядят как «просто цифры». Написать в передаче «маскирование уже прогнали» — значит именно эти цепочки часто оставить нетронутыми. Не полагайтесь на то, что российский документ «сам найдётся».

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

Проверка на месте: канарейка в поле, затем поиск в Network

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

Соберите канарейку без настоящей личности. Для российского номера возьмите вымышленную запись E.164, например +7 999 123-45-67 — не свой номер и не номер клиента. Для формы материкового мобильного 13800138000 — опубликованный макет из рекламы и документации. Почта: canary@example.com. IP: 203.0.113.10. Карта: 4111111111111111. Ключ: одноразовый токен с открытым префиксом, например ghp_ плюс 36 знаков, которые вы придумаете и сразу сочтёте сожжёнными. Не берите ничей настоящий паспорт, СНИЛС или ИНН. Если нужно прогнать контрольную цифру документа, возьмите невозможную дату рождения (1 января 1900), посчитайте последний знак и пометьте абзац как «вымысел».

Вставьте канарейку в обычную заявку: «Пользователь canary@example.com не входит. Перезвоните +7 999 123-45-67. Исходный IP 203.0.113.10. Тестовая карта 4111111111111111. Токен ghp_…. Доставка: Тестовая улица, д. 12, Москва.» После запуска почта, телефон, IP, карта и токен должны появиться в счётчиках попаданий и стать масками как в таблице. «Тестовая улица, д. 12, Москва» должна остаться как есть. Это граница правила, а не ошибка. Если улицу тоже закрыло, вы не на чистом наборе правил или правила расширили — ложные срабатывания смотрите отдельно.

Затем откройте DevTools Network, включите Preserve log и ищите уникальные строки канарейки: +7 999 123-45-67, canary@example.com или полный вымышленный токен. Их не должно быть в строке запроса, query или теле XHR / Fetch и не должно быть в query или теле аналитики. Имя статического скрипта со словами «privacy» или «redact» — ожидаемо. Исходный текст, ушедший рабочим полем, — провал.

1. Соберите заявку из вымышленного E.164, почты example.com, адреса RFC 5737, тестового PAN и токена с префиксом. Нарочно оставьте одну русскую улицу открытым текстом.
2. После запуска сверьте типы попаданий: пять числовых или учётных полей должны быть названы; улица должна остаться в результате.
3. Найдите исходный текст канарейки в Network. Любой рабочий запрос с попаданием значит: ввод покинул эту вкладку.

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

Отработайте границу на странице маскирования, которая открывается без аккаунта

Если нужна страница, где переключатели типов и счётчики попаданий лежат открыто, начните с маскирования данных в очистке данных MakePwd. Страница открывается без регистрации и без входа. Сканирование и маска идут на этой вкладке. По описанию продукта исходный текст не уходит запросом и не пишется в аналитику. Шесть проверяемых типов — те же, что выше: телефон, номер документа, банковская карта, почта, API-ключ и IP. По умолчанию умная маскировка; можно перейти на полную. Одна вставка ограничена 512 КБ. Страница прямо пишет границы: распознаются не все форматы документов, текст не доказывается соответствующим какому-либо требованию, важные исходящие сообщения всё равно нужно перечитывать человеку.

Тренируйтесь только на канарейках. После запуска смотрите сразу три места: счётчики типов попаданий, не задели ли улицу в результате, есть ли исходный текст в Network. Счётчики отвечают «назвали ли нужные типы». Улица отвечает «где правило останавливается». Network отвечает «ушло ли на сервер». Когда все три места сходятся, коллеге можно сказать: я закрыл эти типы, знаю, что адрес ещё на месте, и искал канарейку на проводе.

Параметры слежения в URL — отдельная задача. Если в заявке ещё вставлена полная ссылка с utm_source или fbclid, сначала снимите query по ключу, затем обрабатывайте номера в тексте. Шаги — в Какие данные слежения уходят, если вставить в чат полную ссылку с UTM. Если после маскирования остаётся секрет, который должен дойти без изменений, отправьте его один раз одноразовой ссылкой и оставьте ключ во фрагменте URL #. Целый файл зашифруйте локально в шифровании файлов в .lock / .enc (один файл, не больше 5 ГБ) и затем отправьте через диск или почту. Ни один из этих шагов не требует аккаунта.

Частые вопросы

После звёздочек это ещё персональные данные?

Обычно да. 152-ФЗ называет персональными данными любую информацию о прямо или косвенно определённом человеке. Обезличивание — это когда без дополнительной информации нельзя понять, кому запись принадлежит. Телефон с последними четырьмя цифрами или почта с доменом плюс текст заявки часто собираются обратно. Маскирование по правилам в лучшем случае движется к обезличиванию. Оно им не является.

Может ли маскирование по правилам заменить проверку человеком?

Нет. Правила ловят форму и контрольную цифру, а не смысл. ФИО, адрес, СНИЛС, продиктованные цифры, скриншот и переписанный ключ проходят мимо. Важные исходящие сообщения перечитайте сами. Страница инструмента не заявляет соответствие 152-ФЗ или сертификацию GDPR.

Уходит ли исходный текст на сервер при маскировании?

По описанию продукта сканирование и маска выполняются на этой вкладке. Исходный текст не уходит телом запроса и не пишется в аналитику. Вымышленной канарейкой это можно проверить в Network для одного запуска. Это не доказывает, что расширение никогда не читало поле.

Как отправить секрет, который маскирование не доводит до конца?

Разрозненные телефоны и номера документов закрывайте правилами. Целый пароль, неопубликованный материал или ключ, который должен дойти без изменений, отправьте один раз одноразовой ссылкой и оставьте ключ после # в URL. Целый файл зашифруйте локально в шифровании файлов в .lock или .enc и затем отправьте почтой или через диск.

Три вещи, которые стоит помнить перед следующей отправкой

Первое: вставка — это копирование. Заявка, чат, мониторинг и выгрузка держат по строке. Правка текущей страницы не возвращает текст, который уже ушёл. Второе: правила закрывают только поля с форматом и проверкой. ФИО, адрес, СНИЛС, ИНН, продиктованные цифры и самодельные токены смотрит человек, а хвосты плюс контекст всё ещё могут указать на человека. Третье: проверяйте три места — типы попаданий, предложение, которое хотели оставить, и поиск канарейки в Network.

Если следующий вопрос — должна ли query полной ссылки ехать вместе с отправкой, читайте Какие данные слежения уходят, если вставить в чат полную ссылку с UTM. Если нужно сверить, что открытый текст не покинул вкладку как рабочие данные, читайте Шифрование в браузере: как убедиться, что исходный текст не покинул устройство. Эта заметка проводит только линию, которую можно записать в вывод: что маскирование по правилам может сделать с телом заявки — и чего нельзя утверждать, будто оно это сделало.