PII masking на собеседовании системного аналитика

Зачем нужно маскирование

PII (Personally Identifiable Information) — персональные данные, которые позволяют идентифицировать человека: ФИО, телефон, паспорт, номер карты. В России их защита регулируется 152-ФЗ, в Европе — GDPR, и за утечку компании прилетают реальные штрафы. Маскирование (data masking) — это способ работать с данными, не раскрывая при этом настоящие персональные значения.

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

Типичные сценарии, где нужно маскирование:

• Логи. В логи не должны попадать номера карт и паспортов — их читают разработчики, они уезжают в системы мониторинга, оседают надолго.
• Тестовые контуры. Разработка и тестирование не должны видеть реальные данные клиентов — им хватит правдоподобных, но фейковых значений.
• Аналитика. Многие витрины и отчёты можно строить без настоящих ФИО и телефонов, оперируя обезличенными идентификаторами.
• Обмен с партнёрами. Когда данные уходят наружу, персональные поля должны быть скрыты или заменены.

Статическое vs динамическое

Первое, что стоит развести на собесе, — два принципиально разных подхода к маскированию.

Статическое маскирование обезличивает данные один раз при копировании и сохраняет уже замаскированную версию. Оригинал в этот контур больше не попадает — типичный случай для наполнения dev/test-баз из продакшена.

Прод-база:  Иван Петров
Тест-база:  Имя_X12345

Разработка и тестирование в принципе никогда не видят настоящие персональные данные — их просто нет в этом окружении.

Динамическое маскирование хранит оригинал как есть и маскирует значение «на лету» при чтении, в зависимости от прав пользователя. Данные не дублируются, решение принимается в момент запроса.

Администратор видит:   Иван Петров
Обычный пользователь:   И*** П*****

Ключевая разница для собеса: статическое подходит для непродакшн-контуров, где реальные данные не нужны в принципе; динамическое — для продакшена, где данные должны жить в исходном виде, но показываться по-разному разным ролям.

Методы маскирования

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

• Редактирование (redaction). Значение заменяется на ***. Просто и необратимо, но теряется вся информация — годится для показа, не для аналитики.
• Подстановка (substitution). Реальное значение меняется на правдоподобное фейковое: настоящее ФИО → случайное, но валидное имя. Данные остаются реалистичными для тестов.
• Перемешивание (shuffling). Значения переставляются между строками: колонка остаётся статистически похожей, но конкретную строку с человеком уже не связать.
• Шифрование (encryption). Обратимое преобразование с ключом: имея ключ, значение можно восстановить. Подходит, когда доступ к оригиналу нужен авторизованной стороне.
• Хеширование (hashing). Одностороннее преобразование (например, SHA-256): восстановить нельзя, но одинаковый вход даёт одинаковый хеш. Удобно для джойнов и дедупликации по обезличенному ключу.
• Токенизация (tokenization). Значение заменяется на токен, а соответствие «токен → оригинал» хранится в отдельном защищённом сервисе.

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

Токенизация

Токенизация заменяет чувствительное значение на бессмысленный токен, а таблицу соответствий держит только специальный токен-сервис (vault):

Оригинал: 4111-1111-1111-1111
Токен:    tok_a1b2c3d4

Все системы вокруг работают с токеном, и только токен-сервис знает, какому реальному значению он соответствует. Это даёт два больших плюса:

• Уменьшение PCI-скоупа. Реальные данные карт живут в одном изолированном сервисе, а не размазаны по всем базам и логам. Под требования PCI DSS попадает меньше систем — а значит, дешевле аудит и меньше поверхность риска.
• Сохранение целостности. Токен детерминирован и стабилен, поэтому его можно использовать как внешний ключ (FK) в базе: связи между таблицами не рвутся, хотя настоящих данных карты в них нет.

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

Format-preserving encryption

Format-preserving encryption (FPE) — шифрование, которое сохраняет формат исходного значения: длину, набор символов, структуру.

Оригинал:    4111-1111-1111-1111 (16 цифр)
Зашифровано: 8273-4912-9483-7261 (тоже 16 цифр)

Смысл в том, что зашифрованное значение проходит те же проверки формата, что и оригинал: валидация схемы не падает, а код на приёмнике не нужно менять — колонка как была «16 цифр», так и осталась. Это сильно упрощает внедрение в legacy-системы, где нельзя переписать все проверки под длинный зашифрованный blob. Из стандартизированных алгоритмов на собесе достаточно назвать FF1 и FF3-1 (стандарт NIST).

Частые ошибки

• Путать статическое и динамическое маскирование. Статическое — обезличили один раз и храним копию (dev/test). Динамическое — храним оригинал и маскируем при чтении по правам (прод). Разные задачи, разные механики.
• Считать хеширование панацеей. SHA-256 детерминирован, а у персональных данных низкая энтропия: телефон или карту можно перебрать по словарю. Для защиты нужен HMAC с секретным ключом или соль, иначе «обезличенный» хеш легко восстанавливается.
• Игнорировать целостность связей. Если замаскировать поле случайно и по-разному в разных таблицах, джойны по нему сломаются. Для сохранения связей нужен детерминированный метод (токен или детерминированное шифрование).
• Ломать формат приёмнику. Заменить номер карты на длинный blob там, где ждут 16 цифр, — значит уронить валидацию и downstream-код. Здесь и нужна format-preserving encryption.
• Не назвать нормативку. На вопрос «зачем это» ответ «для безопасности» слабоват. Ждут привязку к 152-ФЗ и GDPR и понимание, какие поля вообще относятся к персональным данным.

Связанные темы

• 152-ФЗ для SA
• GDPR vs 152-ФЗ для SA
• Secrets management для SA
• Logging strategy для SA
• Подготовка к собесу системного аналитика

FAQ

Чем маскирование отличается от шифрования?

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

Когда применять токенизацию, а когда шифрование?

Токенизацию берут, чтобы вынести чувствительные данные (обычно карты) из основных систем в изолированный vault и сократить PCI-скоуп; токен при этом стабилен и годится как ключ. Шифрование удобнее, когда значение должно оставаться в той же базе, но быть нечитаемым без ключа, и когда не хочется зависеть от отдельного сервиса соответствий.

Почему нельзя просто хешировать персональные данные?

Хеш детерминирован, а телефоны, email и номера карт имеют ограниченный набор значений — их можно перебрать по словарю и восстановить исходник. Поэтому «сырой» SHA-256 обезличиванием не считается; нужен HMAC с секретным ключом или соль, чтобы перебор стал невозможен.

Зачем нужно format-preserving encryption?

Чтобы зашифрованное значение сохраняло формат оригинала — длину и структуру. Тогда валидация схемы проходит, а код на приёмнике не приходится переписывать под другой тип данных. Это критично для legacy-систем, где нельзя менять проверки формата.

Это официальная информация?

Нет. Статья описывает стандартные практики защиты персональных данных и общие подходы к маскированию. Конкретные требования зависят от компании, регуляторики (152-ФЗ, GDPR, PCI DSS) и архитектуры проекта.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.