Статьи

Почему в 2025 году без деперсонализации не обойтись: всё о новых требованиях закона и лучших инструментах

С 30 ноября 2024 года в России приняты законы, которые навсегда изменили отношение к персональным данным. Теперь за утечку информации компаниям грозят не только миллионные штрафы, но и уголовная ответственность — до 5 лет лишения свободы.

Законодательство уже работает, а значит, каждая компания, которая хранит и обрабатывает персональные данные, должна не просто «навести порядок», а внедрить эффективные и проверяемые решения по их защите. В этом материале рассказываем, как соблюсти новые требования и подобрать надежные инструменты.

По порядку: законы о деперсонализации и их требования к бизнесу

Основной ФЗ‑152 «О персональных данных» от 27 июля 2006 г.

Установил базовые требования обработки данных.

Получать осознанное и конкретное согласие субъекта на обработку персональных данных.
Не передавать данные третьим лицам без основания.
Обеспечивать защиту персональных данных: использовать сертифицированные ИБ-средства, ограничивать доступ, шифровать данные.
Удалять или обезличивать данные по окончании целей обработки.
Реагировать на утечки и уведомлять Роскомнадзор.
С 1 марта 2023 года уведомлять Роскомнадзор о начале обработки данных, кроме случаев полностью бумажной обработки или систем ГИС.

Постановление Правительства от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»

Обязывает защищать данные при автоматизированной обработке в информационных системах. Документ устанавливает четыре уровня защищенности:

1 уровень — если обрабатываются специальные категории данных (например, здоровье, биометрия, политические взгляды), и утечка может нанести тяжелый вред субъекту (например, дискриминация, уголовное преследование). Требуется максимальная защита (СКЗИ, журналирование, контроль целостности и др.).
2 уровень — если утечка персональных данных общего характера (ФИО, паспорт, адрес) способна нанести средний вред (например, мошенничество, утрата конфиденциальности). Меры схожи с первым уровнем, но допускаются упрощения по криптографии и мониторингу.
3 уровень — вред от утечки незначителен, но данные все еще позволяют идентифицировать личность. Нужна защита от несанкционированного доступа, авторизация, базовые механизмы контроля.
4 уровень — применяется в ограниченных случаях, например, при обезличенных или сильно ограниченных наборах данных, где идентификация субъекта практически исключена. Минимальный набор мер — например, пароли и физическая безопасность.

На практике у большинства компаний уровень защищенности соответствует 2-му или 3-му уровню по Постановлению №1119. Проблема в том, что эти данные редко сосредоточены в одном месте: они «размазаны» по множеству систем: CRM, бухгалтерии, HR-сервисам, внешним интеграциям. Каждая такая точка — потенциальный риск. Именно поэтому требования к деперсонализации касаются не только «основной базы клиентов», но и всех окружных систем, где так или иначе появляются персональные данные.

Шифрование — обязательная мера защиты, если в системе обрабатываются персональные данные 1 или 2 уровня защищенности. Применяются только сертифицированные средства криптографической защиты (СКЗИ), зарегистрированные в ФСБ. Это предотвращает доступ к ПДн даже в случае физического доступа к оборудованию.

Журналирование — фиксация всех действий с ПДн: кто, когда, откуда и какие данные запрашивал, просматривал, изменял или удалял. Журналы защищаются от изменения и хранятся в течение минимум 1 года. Это критически важно для расследования инцидентов и доказательства соблюдения закона при проверках Роскомнадзора или ФСТЭК.

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

Поправки к ФЗ-152: что изменилось в требованиях к локализации персональных данных

С 2011 года компании обязаны хранить и обрабатывать персональные данные граждан РФ только на территории России. С 1 июля 2025 года введен запрет на сбор данных через «чужие» cookie и аналитику (Google Analytics и другие) без локализации или разрешения.

Приказ Роскомнадзора от 5 сентября 2013 г. N 996 «Об утверждении требований и методов по обезличиванию персональных данных»

Устанавливает требования и методы деперсонализации персональных данных.

Деперсонализация ≠ Шифрование. Оба метода защищают данные, но делают это по-разному.

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

Анонимность — идентификация субъекта без дополнительных данных невозможна.
Структурированность — связи между данными сохраняются.
Семантическая целостность — «имя» остается похожим на имя, «дата» — на дату.
Полнота — сохраняются все нужные поля.
Применимость — данные можно обрабатывать как обычно, без восстановления личности.
Релевантность — результат дает те же ответы на запросы, что и исходные персональные данные.

Новые требования по защите данных: что принесли ФЗ-420 и ФЗ-421

Новый административный кодекс вводит штрафы до 500 млн руб. для юридических лиц и до 800 тыс для IT‑директоров. Административные штрафы за утечку зависят от числа затронутых субъектов:

до 10 000 человек — до 3–5 млн руб.;
до 100 000 — еще выше;
крупные утечки — до 500 млн руб.

В УК РФ добавлена статья 272.1 об уголовной ответственности (до 5 лет лишения свободы, ответственность за незаконное хранение, сбор, использование и передачу персональных данных).

Эти меры уже вступили в силу с 30 мая 2025 года.

Главные способы защиты: шифрование и деперсонализация

	Шифрование	Деперсонализация
Что делает	Преобразует данные в нечитабельный вид	Заменяет реальные данные на псевдо-данные
Можно ли восстановить?	Да, с помощью ключа	Нет, восстановить невозможно (или крайне сложно)
Где применяется	Для защиты рабочих данных	Для защиты копий, тестов, аналитики
Пример	Номер паспорта зашифрован в базе и расшифровывается при чтении	Имя и паспорт заменены на фиктивные, но реалистичные
Правовое назначение	Обеспечивает конфиденциальность	Обеспечивает неидентифицируемость

Шифрование требуется в работающих системах, где вы реально обрабатываете персональные данные клиентов — например, в CRM, в интернет-магазине, в приложении банка, на сервере авторизации.

Деперсонализация нужна там, где вам не важно, кто конкретно пользователь, а важно сохранить структуру данных. Она особенно важна, когда данные используются вне продуктивного контура: например, в тестовых средах, где с ними работают внешние подрядчики. Такие среды зачастую не защищены так же строго, как основная инфраструктура, и если в них попадают реальные персональные данные — компания автоматически нарушает закон. Здесь деперсонализация данных — не опция, а обязанность. И если она реализована вручную, через скрипты, или устаревшие ETL-системы, компания по-прежнему в зоне риска. Используемые инструменты не обеспечивают повторяемость и верифицируемость процесса, а значит, не позволяют формально подтвердить соответствие рекомендациям Роскомнадзора.

Когда нужно шифровать, а когда — обезличивать

Вы обрабатываете ПДн в «боевой» системе	Шифрование + Контроль доступа
Вы создаете тестовую/аналитическую копию	Деперсонализация обязательна
Вы передаете данные третьим лицам	Деперсонализация + шифрование
Вы храните данные в облаке	Шифрование, деперсонализация ограничение доступа

Важно!
Шифрование не отменяет необходимости деперсонализации.
Деперсонализация не освобождает от применения СКЗИ (средств криптографической защиты информации) при передаче данных.
В тестовых средах или BI-сценариях только шифрования недостаточно — данные всё равно читаются.

Это особенно важно, когда данные используются вне продуктивного контура: например, в тестовых средах, где с ними работают внешние подрядчики. Такие среды зачастую не защищены так же строго, как основная инфраструктура, и если в них попадают реальные персональные данные — компания автоматически нарушает закон. Здесь деперсонализация данных — не опция, а обязанность. И если она реализована вручную, через скрипты, или устаревшие ETL-системы, компания по-прежнему в зоне риска, поскольку используемые инструменты не обеспечивают повторяемость и верифицируемость процесса, а значит, не позволяют формально подтвердить соответствие методическим рекомендациям Роскомнадзора.

Как выбрать инструмент шифрования базы данных

Категория	Инструмент	Особенности
ФСБ-сертифицированные	КриптоПро CSP, ViPNet, Континент	Используются в госорганах, соответствуют ФЗ
Открытые/корпоративные	OpenSSL, GnuPG, HashiCorp Vault	Для API, PKI, секретов, DevOps
Для СУБД	Transparent Data Encryption (TDE) в Oracle, MS SQL, pgcrypto	Шифруют данные на уровне БД
Хранение файлов	VeraCrypt, BitLocker, LUKS	Шифрование жестких дисков и носителей
TLS и Web	Let's Encrypt, Cloudflare, NGINX	TLS-сертификаты, HTTPS, защита API

Если у вас база данных с персональными данными клиентов — включите TDE в вашей СУБД (например, Oracle, PostgreSQL), добавьте шифрование на уровне поля, если нужно.
Если вы передаете данные по сети (API, веб) — используйте TLS/HTTPS, защитите ключи в HashiCorp Vault или GnuPG.
Если вы госкомпания или работаете с государством — применяйте только сертифицированные СКЗИ (КриптоПро, ViPNet, Континент), иначе нарушите закон.
Если у вас разработка или DevOps-среда — используйте шифрование переменных и секретов в CI/CD (например, Vault + TLS).
Если вы работаете с файлами (архивы, резервные копии) — шифруйте носители (VeraCrypt, BitLocker) и храните отдельно ключи.

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

В 2022 году зарубежные провайдеры — включая популярные системы для деперсонализации — завершили деятельность в РФ. Российские IT-службы остались без привычных решений и вынуждены были переходить на неофициальные скрипты и устаревшие ETL-процессы.

ETL-процессы

ETL — аббревиатура от Extract, Transform, Load, что в переводе означает извлечение, преобразование и загрузка. Такие решения часто применяются в построении хранилищ данных, BI-систем, а также в некоторых случаях — для деперсонализации.

Сначала данные извлекаются (Extract) из источника — например, из базы клиентов, CRM, бухгалтерской системы или другого сервиса. Затем они проходят этап преобразования (Transform): данные нормализуются, фильтруются, очищаются, и при необходимости, обезличиваются или агрегируются. И наконец, данные загружаются (Load) в новое хранилище или тестовую среду, где с ними можно безопасно работать.

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

ETL-инструменты обычно требуют выделения инфраструктуры: серверов, хранилищ, ресурсов под обработку.
Переносят данные между системами, что само по себе создает дополнительную точку риска утечки. Во время перемещения данные могут попасть в лог, кэш, временную таблицу — и никто не гарантирует, что эти следы будут полностью удалены. В-третьих, такие решения плохо масштабируются: если объем базы — десятки терабайт, обезличивание может занять сутки, и это становится узким местом всего релизного цикла.
Большинство ETL-решений плохо справляются с автоматическим поиском персональных данных. Чтобы правильно настроить обезличивание, сначала нужно вручную «промаркировать» все поля, где есть ФИО, адреса, телефоны и прочее. Это трудозатратно и ненадежно: легко пропустить что-то важное.
ETL требует участия инженеров со специфической квалификацией — их сложно найти, долго обучать и дорого содержать. Особенно если инфраструктура построена на западных платформах, которые после 2022 года ушли с российского рынка и больше не поддерживаются.

В условиях современных требований (высоких объемов данных, более строгого законодательства и необходимости быстрого Time to Market) писать собственное решение по деперсонализации на основе ETL — практика устаревшая и неэффективная.

Готовые инструменты: сравнение по главным параметрам

Инструмент (вендор)	Подход	Автопоиск ПДн (data discovery)	Скорость (заявленная)	Цена/ лицензия	Доступность/поддержка в РФ	Ключевые особенности
DataSan («Перфоманс Лаб»)	Статическая деперсонализация (маскирование), работа внутри контура	Да: автоматический поиск полей с ПДн, профилирование	>1 ТБ/час	Коммерческая	Да; внесен в реестр российского ПО (№22780 от 06.06.2024)	Сохраняет структуру/смысл данных; быстрое внедрение (от 1 дня); не требует выноса данных за периметр
Сфера: Обезличивание данных (Т1 / SFERA)	Статическая деперсонализация (в т.ч. для тестовых баз/датасетов)	ML-подход к полноте/точности обезличивания	До 2,5 ТБ в сутки	Коммерческая	Да; внесен в реестр российского ПО (№158ч67), есть сертификат ФСТЭК	Поддержка Oracle/MS SQL/Postgres, файлы/«большие данные»; есть отдельный модуль для Hadoop.
Oracle Data Masking and Subsetting (Oracle)	Статическая деперсонализация для баз данных Oracle	Да: компонент Data Discovery (ADM, Sensitive Types)	Не раскрываются	Отдельно лицензируется (enterprise-опция)	Нет, операции/сервисы Oracle в РФ официально прекращены	Маскирование + сабсеттер; корпоративный контроль политик
ARX (open-source)	Анонимизация по моделям (k-anon, l-div, t-clos., DP)	Автоскан исходников не заявлен: фокус на моделях/трансформациях	Не указаны	Условно бесплатно	Доступен, не лицензирован	Ручная конфигурация и настройка, работает с MS SQL, DB2, MySQL и PostgreSQL.
Модуль «Деперсонализация клиентских данных» (HF Labs)	Необратимое хеширование	Нет, работает на заранее определенных полях в системе «Единый клиент»	Не указано	Enterprise-решениедля пользователей “Единого клиента”	Доступен, не внесен в реестр российского ПО	Защищает от ошибочной деперсонализации, в случае если у клиента есть открытые договора; не подходит для тестирования

DataSan («Перфоманс Лаб»)

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

Автопоиск данных: встроенный механизм профилирования автоматически находит все поля с персональными данными, включая скрытые и нестандартные типы хранения.

Скорость обработки: более 1 ТБ/час; в кейсе с крупным банком база объемом 37 ТБ была полностью обезличена за 35 часов.

Стоимость: коммерческая лицензия, прайс-лист не публичен; поставляется с полным сопровождением внедрения и поддержки.

Доступность в России: внесен в реестр российского ПО (№22780 от 06.06.2024), официально поддерживается и активно внедряется в финансовом и корпоративном секторе.

Основные сценарии: банки и страховые компании, системная интеграция и разработка ПО, маркетинг и аналитика, облачные провайдеры и e-commerce. Используется для деперсонализации данных в тестовых и аналитических средах, интегрируется в CI/CD-процессы, помогает снизить риск утечек и соответствовать новым требованиям ФЗ-152 и Приказа Роскомнадзора №996.

Сайт: https://datasan.ru/

Сфера: Обезличивание данных (Т1 / SFERA)

Методы маскирования: поддерживает статическую деперсонализацию для различных источников данных (Oracle, MS SQL, PostgreSQL, Hadoop и файловые форматы). Реализованы классические техники замены и маскирования значений с сохранением формата.

Автопоиск данных: заявляется использование машинного обучения для более точного и полного выявления персональных данных в базах и хранилищах.

Скорость обработки: от 800 до 90 тыс. строк в секунду на одном поде, в сутки в рамках одного потока — до 2,5 ТБ.

Стоимость: коммерческая лицензия; цена зависит от количества параллельных процессов обезличивания.

Доступность в России: продукт включен в реестр российского ПО (№158ч67), есть сертификат ФСТЭК; ориентирован на компании, которым важно выполнение требований локальных регуляторов.

Основные сценарии: создание обезличенных копий рабочих баз для тестирования и разработки, обеспечение безопасной аналитики на больших массивах данных, соответствие требованиям российского законодательства (ФЗ-152, Приказ Роскомнадзора №996).

Сайт: https://www.sferaplatform.ru/obezlichivanie

Oracle Data Masking and Subsetting (Oracle)

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

Автопоиск данных: включает модуль Data Discovery, который помогает выявлять чувствительные поля и автоматизировать настройку профилей маскирования.

Скорость обработки: конкретные показатели Oracle не раскрывает; продукт ориентирован на крупные корпоративные базы данных и тесно интегрирован с Oracle Enterprise Manager.

Стоимость: лицензируется отдельно в рамках Oracle Database Enterprise Edition, относится к категории дорогих корпоративных решений.

Доступность в России: официальная поддержка и продажи Oracle в РФ прекращены, легальное внедрение затруднено.

Основные сценарии: создание безопасных копий баз данных для тестирования, разработки и аналитики при сохранении структуры и соответствии требованиям регуляторов (GDPR, ФЗ-152 и др.).

Сайт: https://www.oracle.com/security/database-security/data-masking/

ARX (open-source)

Методы маскирования: академические модели анонимизации — k-анонимность, l-diversity, t-closeness и дифференциальная приватность. Поддерживает генерацию преобразованных датасетов с сохранением логических связей и структуры.

Автопоиск данных: не предоставляет; пользователь самостоятельно определяет атрибуты, подлежащие анонимизации.

Скорость обработки: зависит от объема данных и выбранных моделей; при очень больших наборах возможны проблемы с масштабируемостью.

Стоимость: полностью бесплатный open-source проект, доступный для скачивания и использования без ограничений.

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

Основные сценарии: исследовательские проекты, академическая среда, пилотные внедрения, а также компании, которым важно использовать строгие модели анонимизации при подготовке датасетов для публикаций, анализа или обучения моделей машинного обучения.

Сайт: https://arx.deidentifier.org/anonymization-tool/

Модуль «Деперсонализация клиентских данных» (HFLabs Uniform Client)

Методы маскирования: необратимое хеширование, включая данные из исторических карточек клиентов, поисковые индексы и информацию, использовавшуюся для выявления дубликатов.

Автопоиск данных: работает на заранее определенных полях клиентских карточек и интеграциях системы «Единый клиент»; автоматического ML-обнаружения персональных данных не заявлено.

Скорость обработки: публичных данных о производительности нет.

Стоимость: решение предлагается в рамках платформы HFLabs, по запросу.

Доступность в России: разработан российской компанией, но нет данных о внесении в реестр российского ПО.

Основные сценарии применения:

обезличивание клиентских данных после завершения срока хранения по требованиям ФЗ‑152 при сохранении аналитических связей;
возможность распознавания “экс‑клиента”, если он снова обращается, путем сравнения нового хеша с базой существующих, даже при частичных изменениях данных (смена фамилии, формат адреса, опечатки и пр.);
предотвращение ошибочного обезличивания, когда у клиента сохраняются активные договоры или согласия — в таких случаях деперсонализация не выполняется.

Сайт: https://hflabs.ru/uniform-client/depersonalizaciya-klientskih-dannyh

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

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

Дальнейшие действия: внедряем процесс по шагам

Аудит данных — определите, какие персональные данные вы храните и где именно они находятся (базы, CRM, аналитика, тестовые среды).
Оценка рисков — проанализируйте, какие сценарии утечки наиболее вероятны и чем они грозят бизнесу.
Выбор подхода — определите, какой метод обезличивания подходит под ваши задачи и риски: маскирование, анонимизация, хеширование или их комбинация.
Инструменты — сравните решения по ключевым параметрам: скорость обработки, поддержка автопоиска ПДн, соответствие законодательству, доступность в России.
Пробный период — проведите пилотный проект, чтобы выбрать технологию и попробовать решение именно для ваших систем.
Внедрение в процессы — встройте деперсонализацию в CI/CD, тестовые и аналитические среды, чтобы защита была автоматической и непрерывной.
Контроль и поддержка — регулярно проверяйте корректность работы инструмента, обновляйте методики и фиксируйте результаты для возможных проверок Роскомнадзора.

Василий Жидков

2026-02-23 12:41