Статьи https://datasan.ru ru Mon, 23 Mar 2026 12:49:41 +0300 Обезличивание данных в базах: в чем сложность и как организовать процесс https://datasan.ru/tpost/9kyc0sexa1-obezlichivanie-dannih-v-bazah-v-chem-slo https://datasan.ru/tpost/9kyc0sexa1-obezlichivanie-dannih-v-bazah-v-chem-slo?amp=true Mon, 16 Mar 2026 12:41:00 +0300 Simon Einstein

Обезличивание данных в базах: в чем сложность и как организовать процесс

Деперсонализация кажется простой задачей, пока не сталкиваешься с реальностью. На практике это полноценный инженерный вызов, сочетающий профилирование, проверку бизнес-логики, оптимизацию и работу с нетривиальными особенностями инфраструктуры. В этой статье мы разобрали технические сложности, через которые проходят команды, когда пытаются организовать обезличивание в больших системах, — и решения, позволяют пройти этот путь.
С 30 ноября 2024 года вступили в силу важные изменения в законодательстве о защите данных. Теперь за нарушения, связанные с обработкой и защитой персональных данных, появилась уголовная ответственность для сотрудников, отвечающих за информационную безопасность и работу с данными.
Помимо этого, введены оборотные штрафы: за повторные нарушения компания может заплатить до 3% от годового оборота. Суммы ощутимые, особенно для бизнеса, который работает с большими объемами пользовательских данных.
Когда мы обсуждаем нововведения с инженерами, быстро становится ясно: один штраф стоит дороже, чем внедрение нормального процесса обезличивания. И уж точно не стоит того, чтобы рисковать уголовной ответственностью. Поэтому сегодня вопрос «нужно ли обезличивать?» уже не стоит — стоит вопрос, как сделать это эффективно и безопасно.

Как правильно выделить и обработать персональные данные

В процессе обезличивания мы опираемся на два ключевых понятия: профилирование и деперсонализация.
Профилирование — это поиск полей, содержащих персональную информацию. На самом деле мы можем искать не только ПДн: в разных проектах нас просили находить размер каски, обуви и другие специфичные параметры — всё это решалось без проблем.
Деперсонализация (обезличивание) — следующий шаг. Это изменение найденных данных таким образом, чтобы при возможной утечке они не представляли ценности для злоумышленников и не могли быть использованы против пользователя или компании. Неважно, относятся ли данные к категории персональных или к любому другому чувствительному типу — принцип один и тот же.
На первый взгляд кажется, что определить персональные данные достаточно просто: фамилия, имя, отчество, номер телефона, паспорт, ИНН, СНИЛС — всё это очевидные категории. Но на практике возникает вопрос: как отличить, например, ИНН от любого произвольного набора цифр?
Чтобы минимизировать ложные срабатывания, мы добавляем дополнительные проверки:
  • для СНИЛС используем проверку контрольной суммы;
  • для паспортных данных анализируем первые четыре цифры, чтобы убедиться; что это действительно паспорт, а не случайная последовательность.
Отдельная важная задача — сохранение консистентности. Когда мы обезличиваем данные из разных баз, одно и то же имя или номер телефона должны превращаться в одинаковые значения. Это критично для последующего анализа и работы с наборами данных, чтобы обезличенные данные оставались полезными и связными.
Ещё один частый сценарий — географически распределенные дата-центры. Между ними может не быть связи вовсе, но при этом важно, чтобы данные в разных хранилищах обезличивались одинаково. Мы решаем и такую задачу: две независимые базы должны выдавать совпадающие обезличенные значения для одних и тех же исходных данных.
Есть и другая особенность, с которой сталкиваются команды тестирования. Если на вход тестам вместо фамилии и имени приходит случайный набор букв, такие значения легко ломают логику сценариев. Поэтому мы научились преобразовывать реальные данные в корректные, естественно выглядящие аналоги: превращать Васю Петрова в Петра Иванова, генерировать валидные номера телефонов и паспортов, корректно подбирать даты рождения.
Бывают и более специфичные запросы. Например, страховая компания просила сохранить информацию о том, что клиент старше 18 лет, но при этом «сдвигать» дату рождения так, чтобы она обязательно попадала в первую или вторую половину месяца — потому что на этом основана внутренняя логика расчета коэффициентов. Таких кейсов у нас накопилось много, и каждый требовал отдельного подхода.

В итоге сформировалась большая библиотека способов корректного и устойчивого обезличивания данных — и это, как оказалось, куда сложнее, чем кажется на первый взгляд.

Технические сложности профилирования

Понять, какие сущности мы ищем

Первый шаг — понять, с какими видами данных вы работаете. Типовой список включает ПДн физических лиц включает:
  • ФИО
  • Адрес
  • Телефонный номер
  • Паспортные данные
  • СНИЛС
  • ОГРН
  • ИНН
  • Номер счетов / банковских карт
Однако в зависимости от домена персональные данные могут относиться не только к физическим лицам: могут быть задействованы и юридические лица, и другие типы сущностей. На этом этапе важно четко зафиксировать, что именно считается чувствительными данными в вашем контуре

Определить методы поиска

Даже разобравшись с тем, что искать, нужно понять, как это искать. Мы выделяем три основных метода:
  • метаданные;
  • словари;
  • регулярные выражения.
У вас могут появиться дополнительные методы, но эти три — основа.

Собрать данные для этих методов

Чтобы методы профилирования работали корректно, требуется предварительно собрать и подготовить данные. Это включает:
  • наполнение словарей фамилиями, именами и другими возможными значениями;
  • создание и отладку регулярных выражений для структурированных типов данных (например, ИНН, СНИЛС и т. д.);
  • поддержку и обновление этих словарей и шаблонов по мере появления новых форматов и правил.
Это трудоемкий этап, без которого невозможно добиться точного распознавания чувствительных данных.

Собрать движок профилирования

Когда данные готовы, нужно собрать движок, который умеет всё это применять. Если база данных большая, движок придётся долго оптимизировать, чтобы он справлялся с нагрузкой, корректно масштабировался и при этом оставался достаточно быстрым.

Разобраться с архитектурной дельтой

Даже если профилирование прошло успешно и у вас есть готовый профиль данных, работа на этом не заканчивается. Базы со временем обновляются: появляются новые поля и таблицы. Значит, профилирование нужно выполнять повторно — хотя бы по дельте изменений. Это также должно быть заложено в архитектуру движка: инструмент обязан уметь находить новые сущности без полного пересканирования всего хранилища.

Технические сложности деперсонализации

Уникальные сущности и «забытые» места хранения данных

Может показаться, что достаточно обезличить основные таблицы — и работа сделана. На практике это далеко не так. Важно отметить, что пример далее приведен на базе Oracle, и часть подобных проблем специфична именно для этой СУБД. В других системах хранения данные сложности могут проявляться иначе или не встречаться вовсе.

Material View

Физический объект базы данных, который содержит результат выполнения запроса. Материальные представления могут содержать слепки данных, которые не обновились после обезличивания основной таблицы. Поэтому они должны входить в общий контур обработки.

Material View Log

Рядом с ними в Oracle существует ещё одна специфичная сущность — Material View Log. Это вспомогательный физический объект для оптимизации работы с материальными представлениями (позволяет выполнять fast refresh вместо complete refresh). С точки зрения обезличивания не вызывает дополнительных задач, но становится источником серьезных проблем при параллельной обработке данных. В процессе вы рискуете получить взаимные блокировки и остановить весь пайплайн.
Отключить Material View Log нельзя — его приходится удалять и затем восстанавливать. Это нужно учитывать и вписывать в общий процесс обработки данных.

Constraints

Правила, которые добавляются при изменении/добавлении данных в таблицу. Даже если вы умеете корректно работать с нужными полями, всегда существуют ограничения в базе. Например:
  • дата закрытия договора не может быть раньше даты открытия;
  • связанные значения должны оставаться согласованными.
Все такие ограничения тоже нужно профилировать и учитывать при обезличивании. Иначе результат будет некорректным, а база — потенциально сломанной.

Проблемы при пересоздании базы данных

JDK и Java-объекты

В ряде кейсов при восстановлении базы мы сталкивались с тем, что в Oracle:
  • отсутствует возможность компилировать Java source;
  • версия JDK отличается от ходовой.
В результате часть логики, завязанной на Java внутри БД, просто перестает работать. Исправляется это довольно приземленно — переустановкой JDK и приведением версии к нужной.

Индексы в невалидном состоянии

При копировании часть индексов оказывается сломанной, что приводит к остановкам при обновлении таблиц.
Чаще всего это всплывает не на «боевых» таблицах, а на:
  • архивных таблицах;
  • пользовательских слепках/копиях, которые когда-то сделали «на всякий случай» и про них забыли.
Один из обязательных шагов — научиться обнаруживать и корректно обрабатывать такие индексы: либо чинить, либо переcоздавать, либо исключать эти объекты из обработки по согласованным правилам. Иначе процесс обезличивания будет регулярно ломаться на забытых и «заброшенных» участках базы.

Проблемы с настройками баз данных и таблиц

Низкое значение Initrans

Один из характерных примеров — параметр INITRANS в Oracle. Он отвечает за количество DML-запросов, которые могут выполняться параллельно на записях внутри блока данных.
Когда таблица большая и активно обновлялась, ее блоки могут иметь слишком низкое значение INITRANS. В результате при массовом обновлении данных мы параллельно обращаемся в разные блоки и начинаем блокировать сами себя, создавая задержки и замедляя процесс обезличивания.
Исправить ситуацию простым изменением настройки нельзя: для применения потребуется MOVE, а это уже отдельная трудоемкая операция, потенциально влияющая на структуру таблицы. Поэтому на практике проблему приходится решать ручной обработкой взаимных блокировок.

Ограничение свободного места в tablespace

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

Валидация отдельных сущностей

Отдельная группа проблем — корректность данных после обезличивания.
Во-первых, это техническая валидация. Например:
  • Прохождение котрольных суммы (СНИЛС, ИНН и т. д.);
  • корректность формата имени;
  • структуры номера документа.
Если такие проверки не пройдены, приложение может отказать на ровном месте, потому что формат данных перестанет соответствовать ожиданиям.
Во-вторых, есть валидация сохранения бизнес-логики, которую нельзя игнорировать. Например:
  • дата закрытия договора не может быть раньше даты открытия;
  • дата рождения должна соответствовать паспортным данным;
  • связанные сущности должны оставаться согласованными.
Все эти правила должны учитываться прямо в методах обезличивания, иначе база после обработки окажется в неконсистентном состоянии и вызовет дефекты в потребляющих системах.

Оптимизация алгоритмов обезличивания

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

Распараллеливание процессов

Для крупных БД необходимо уметь распараллеливать обработку. Если ваше решение основано, например, на stored procedures или схожем подходе, нативной поддержки параллелизма там обычно нет.
Значит, придется придумывать дополнительный механизм:
  • запускать отдельные jobs;
  • управлять ими через планировщики;
  • контролировать распределение нагрузки.
И это само по себе становится отдельной инженерной задачей.

Оптимизация алгоритмов

Даже если алгоритмы работают корректно, на практике почти всегда оказывается, что скорость обработки оставляет желать лучшего. Массовые обновления, большие объемы данных, сложные проверки и валидации — всё это требует оптимизации.
Иногда приходится пересматривать часть логики, перерабатывать методы или менять подход к обработке данных, чтобы уложиться в адекватное время выполнения.

Пример решения с Oracle

Изначально у нас был простой и понятный конвейер. Один общий планировщик проходил по списку таблиц, которые нужно обезличить.
Старый процесс:
Для каждой таблицы мы:
  1. отключали индексы и триггеры;
  2. запускали через планировщик набор работ, которые выполняли обновления;
  3. по завершении возвращали индексы и триггеры обратно.
Так мы проходили все таблицы по очереди.
Но когда мы обезличивали данные в одном из банков, оказалось, что такой процесс перестал справляться с нагрузкой.
На графике утилизации CPU выше видно множество «пустых» участков⁠ — ресурсы простаивали, а значит, мы теряли время. Для больших объемов данных это неприемлемо.

Мы полностью пересобрали процесс, чтобы устранить простои и максимально загрузить доступные ресурсы.
Теперь пайплайн выглядит так:
  • Первый планировщик проходит таблицы в прямом порядке и обрабатывает крупные таблицы.
  • Второй планировщик идет навстречу первому, но работает с мелкими таблицами — в обратном порядке.
Оба планировщика выполняют подготовку таблиц: отключают индексы, триггеры и запускают обновления.
Завершение же процесса вынесено отдельно:
  • Третий планировщик занимается включением индексов и триггеров, потому что это длительная операция, которая не должна блокировать основной поток обработки.
На выходе — новый график утилизации CPU, где «провалов» практически нет. Все ресурсы загружены равномерно, а процесс обезличивания работает заметно быстрее.

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

Дальнейшие планы по продукту DataSan

  • После нескольких лет работы над ядром мы пришли к тому, что пора развивать пользовательский интерфейс. Это одно из наших ближайших направлений — сделать работу с инструментом более удобной и прозрачной.
  • Параллельно мы развиваем новый модуль усечения данных. На Oracle он уже доступен в стабильной поставке. Этот модуль позволяет значительно сокращать время обезличивания в тех случаях, когда нет необходимости обрабатывать всю базу целиком.
  • Усечение можно выполнять по разным параметрам — не только по дате, но и, например, по фамилиям или сериям паспортов. Мы планируем расширить поддержку и вынести модуль за пределы Oracle, чтобы он был доступен в других СУБД.
  • Разумеется, продолжаем развивать и профилирование — это один из ключевых и наиболее трудоемких этапов, который требует постоянного улучшения.
]]> Почему в 2025 году без деперсонализации не обойтись: всё о новых требованиях закона и лучших инструментах https://datasan.ru/tpost/ylp0tubf11-pochemu-v-2025-godu-bez-depersonalizatsi https://datasan.ru/tpost/ylp0tubf11-pochemu-v-2025-godu-bez-depersonalizatsi?amp=true Mon, 23 Feb 2026 12:41:00 +0300 Василий Жидков

Почему в 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. Контроль и поддержка — регулярно проверяйте корректность работы инструмента, обновляйте методики и фиксируйте результаты для возможных проверок Роскомнадзора.
]]>