Маскирование PII: чем оно отличается от анонимизации и где применяется

Прямой ответ

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

• Маскирование (masking). Частичное сокрытие значения при отображении: +7 9** *** **12, Иванов И. И.. Данные остаются теми же, меняется только представление. Обратимо в смысле наличия исходного значения в системе.
• Псевдонимизация. Замена идентифицирующего поля на псевдоним при сохранении возможности вернуть исходное значение с помощью отдельного ключа. Данные остаются персональными, но прямой идентификатор отделён.
• Анонимизация. Необратимое преобразование, после которого субъект не может быть определён. Только анонимизированные данные перестают быть персональными.

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

Где что применять:

-- детерминированная псевдонимизация идентификатора
SELECT encode(hmac(customer_id::text, current_setting('app.pii_key'), 'sha256'), 'hex') AS customer_pseudo,
       left(full_name, 1) || '***' AS name_masked,
       date_trunc('month', birth_date) AS birth_month
FROM customers;

Практические правила:

1. Маскирование — на уровне представления, а не «в базе как попало». Исходные значения нужны бизнесу; скрывать их следует там, где они не нужны.
2. Ключ псевдонимизации хранится отдельно. Если ключ лежит в той же базе, псевдонимизация ничего не даёт — см. шифрование данных в покое.
3. Логи — главный канал утечки. Значения персональных полей попадают в стектрейсы, отладочные выводы и сообщения об ошибках. Нужен явный слой redaction — см. структурированные логи.
4. Агрегирование с малыми группами опасно. Средний доход по группе из двух человек раскрывает данные обоих; применяется порог минимального размера группы.

Практика: копия БД для разработки

Задача: дать команде рабочую копию продакшен-базы без передачи персональных данных.

1. Определяем перечень полей. Отдельный документ: какие поля в каких таблицах являются персональными, включая неочевидные (комментарии операторов, вложения, IP-адреса).
2. Выбираем стратегию по типу поля. Имена и адреса — генерация правдоподобных значений; e-mail и телефон — детерминированная подстановка (чтобы связи между таблицами сохранялись); суммы и даты — сохраняем, если они не идентифицируют; свободный текст — очистка или удаление.
3. Детерминированность обязательна. Один и тот же клиент должен получить один и тот же псевдоним во всех таблицах, иначе тесты на связях ломаются.

import hashlib

SALT = os.environ["MASK_SALT"]

def pseudo(value: str) -> str:
    return hashlib.sha256(f"{SALT}:{value}".encode()).hexdigest()[:12]

def mask_email(email: str) -> str:
    return f"{pseudo(email)}@example.test"

4. Проверяем результат. Автоматический тест ищет в копии шаблоны e-mail, телефонов и номера документов вне разрешённых доменов; нахождение — ошибка пайплайна.
5. Обновляем копию регулярно и тем же пайплайном. Ручное «скопировать и почистить» неизбежно пропускает новые таблицы и поля.

Рекомендации:

1. Ведите реестр полей с персональными данными. Без него любая новая таблица становится неконтролируемым каналом.
2. Маскируйте и в журнале аудита. Журнал нужен для расследования, но не должен дублировать чувствительные значения — см. audit log.
3. Проверяйте анонимизацию, а не полагайтесь на неё. Перед публикацией датасета оцените риск связывания с внешними данными и размер наименьших групп.
4. Не анонимизируйте там, где нужна точность. Для финансовых расчётов и доставки нужны реальные данные; задача решается ограничением доступа, а не искажением.

Практический сценарий: персональные данные в логах

Контекст: при разборе инцидента в системе агрегации логов обнаружили полные номера карт и адреса клиентов.

1. Причина. Логировался весь объект запроса целиком (logger.info("payload", payload=body)), включая чувствительные поля; отдельно стектрейсы сериализовали объекты ORM со всеми атрибутами.
2. Масштаб. Логи хранились 30 дней и были доступны широкому кругу инженеров, то есть доступ к персональным данным был неконтролируемым.
3. Действия. (а) Ввели слой redaction со списком полей и регулярными шаблонами для номеров документов и карт; (б) запретили логирование объектов целиком — только явный набор полей; (в) сократили срок хранения логов с персональными данными и очистили накопленное; (г) ограничили доступ к потоку логов.
4. Проверка. Добавили тест, который отправляет запрос с заведомо чувствительными значениями и проверяет, что они не появляются в логах.
5. Профилактика. Правило закреплено в код-ревью и в шаблоне логгера: сериализация по списку разрешённых полей, а не по всему объекту.

Вывод: утечка персональных данных чаще происходит через вспомогательные каналы — логи, копии БД, отчёты, — а не через основной API. Инвентаризация этих каналов важнее добавления новых средств защиты в одном месте.

FAQ

Считается ли хешированный e-mail анонимизацией? Нет, если хеш детерминированный и без секрета: пространство e-mail конечно и перебирается по словарю. Такой хеш — псевдоним, а данные остаются персональными. Для приблизительной необратимости нужен секретный ключ, хранимый отдельно.

Можно ли использовать маскированные данные в продакшен-отчётах? Да, если для задачи не нужны исходные значения: счётчики, динамика, распределения. Нельзя, когда требуется связать данные с конкретным клиентом или выполнить обязательство перед ним.

Что делать с персональными данными в free-text полях? Наиболее надёжно — не хранить там персональные данные и ограничивать ввод. Для уже накопленного текста применяют распознавание сущностей и замену, но гарантировать полноту такого подхода нельзя, поэтому доступ к полям ограничивают.

Как маскирование связано с правом на удаление? Маскирование не заменяет удаление: если субъект требует удаления данных, маскированные записи и псевдонимы всё равно должны быть удалены там, где нет законного основания для хранения. Механика — в статье про право на забвение.

Источники: GDPR Article 4 (definitions), PostgreSQL pgcrypto, Wikipedia (data anonymization) — ссылки в шапке.