Все знают, что ПДн — это скучная история про соблюдение законов.
Ну, какие-то там штрафы.
Ну, подумаешь, очередная крупная контора засветилась в каком-то скандале про утечку.
Отношение обычно такое — «разбираться лень, нас это не коснется».
Но если присмотреться, — тема довольно интересная, потому что влияет на архитектуру систем.
Расскажу, опираясь на основные сценарии, ради которых придуманы законы про ПДн.
———
Сцена 1. Приходит в поддержку пользователь.
И говорит: «Я — Вася Пупкин. Расскажите-ка мне обо всех моих персданных, которые вы храните и обрабатываете.
Пришлите список конкретных значений, в соответствии с ФЗ-152 от 27.07.2006.».
Да, прямо так и говорит 🙃
И тут начинается суета: запрос проваливается в третий уровень саппорта и те начинают судорожно скрести по сусекам, собирая с разных баз данных разные следы этого пользователя.
Затем человек говорит:
«а теперь — удалите всё».
И они пытаются удалить, и даже удаляют всё что нашли.
Сцена 1.1 Васе приходит емейл- и смс-рассылка.
И тут становится понятно, что удалили не всё.
Вася обращается в РКН.
РКН выставляет компании штраф.
В чем суть:
Мы должны уметь рассказать пользователю о списке хранимых ПДн и удалить их по запросу. При невыполнении — штраф до 300к за каждый случай нарушения — читай, за каждого пользователя, который пожаловался в РКН.
Казалось бы — несложное требование. Базовое, я бы сказал. Но если ПДн размазаны по сотне сервисов, ПДн собираются в сотне сценариев, и при этом нет единого реестра — выполнить это требование невозможно.
Поэтому важно на этапе проектирования архитектуры закладывать либо централизованное хранилище, либо реестр + сигнал об удалении.
———
Сцена 2. Приходит в поддержку следак.
И говорит: «Есть такой-то фигурант, Вася Пупкин. Расскажите мне всё, что знаете о нём: какие объявления размещал, какие номера телефонов использовал».
И опять начинается суета. ПДн Васи Пупкина ведь удалили в сцене 1.
В чем суть: даже после удаления, через 3 года, нужно уметь рассказать товарищу следователю, что делал тот или иной бандит. Тот самый «закон Яровой» (ФЗ-374 от 06.07.2016) и поправки от 01.01.2026.
Поэтому удаление должно быть «логическим» — данные помечаются как удаленные, уходят в архив / на холодное хранилище, и становятся недоступны самому пользователю. Но должна быть возможность поднять эти данные.
———
Сцена 3. Плохие парни проникают в сеть конторы, сливают БД и продают дамп в даркнете
Пользователям начинают писать / звонить всякие мошенники с целью развода. Слитые данные помогают негодяям повысить конверсию в мамонта. Вася Пупкин становится жертвой социнженерии и переводит все накопления
А конторе что? Раньше были смешные штрафы, типа 50к рублей. И максимум что было — шумиха из-за очередного слива, и некоторый репутационный ущерб компании. Но среди всех случаев не было такого чтобы кого-то серьезно нахлобучили.
С 2025г ввели оборотный штраф: 1-3% от выручки за год / не менее 20млн, не более 500млн рублей.
Теперь не смешно.
В чем суть: подход тут должен быть примерно как с паролями — ПДн нельзя хранить в открытом виде. Шифруйте, солите, храните ключи и соли отдельно. Храните в БД сервисов хэши, а сами ПДн в шифрованном виде храните в отдельных БД, к которым доступа нет ни у кого. Это не исключает риск утечки, но снижает вероятность и последствия.
———
Это всё, конечно, доп сложность для разработки. Но если сложить все составляющие, то получается довольно интересная архитектура:
1. Сами ПДн хранятся шифровано в едином реестре, максимально закрученном по доступам и сетевым правилам.
2. Сервисы с бизнес-логикой хранят хэши ПДн. Если нужно, — обменивают хэш на реальное значение у единого реестра из п.1
3. Админка к этому реестру, куда имеют доступ юристы и поддержка.
4. Сервис-адаптер для всяких интеграций с гос сервисами типа госуслуг.
Проблема в том, что большинство крупных сервисов — это набор легаси, и ПДн, скорее всего, уже размазаны по сотне сервисов.
И по сути нужно сделать большой рефакторинг, стоимостью в 100 человеко-лет.