Статьи

Почему в 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
  1. Если у вас база данных с персональными данными клиентов — включите TDE в вашей СУБД (например, Oracle, PostgreSQL), добавьте шифрование на уровне поля, если нужно.
  2. Если вы передаете данные по сети (API, веб) — используйте TLS/HTTPS, защитите ключи в HashiCorp Vault или GnuPG.
  3. Если вы госкомпания или работаете с государством — применяйте только сертифицированные СКЗИ (КриптоПро, ViPNet, Континент), иначе нарушите закон.
  4. Если у вас разработка или DevOps-среда — используйте шифрование переменных и секретов в CI/CD (например, Vault + TLS).
  5. Если вы работаете с файлами (архивы, резервные копии) — шифруйте носители (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
Грамотно внедренные инструменты обезличивания дают не только юридическую защиту. Они помогают ускорять разработку, тестировать новые продукты без риска утечек, безопасно делиться данными внутри команды и использовать их для аналитики и машинного обучения.
Иными словами, деперсонализация превращается в мост между безопасностью и гибкостью: компания соблюдает требования регулятора и при этом сохраняет возможность работать с данными так, как того требует рынок.

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

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