Маскирование данных: что это, виды и как выбрать решение
Проверено экспертной редакцией SecRadar · по первоисточникам ФСТЭК / ФСБ / Банка России
Маскирование данных — техника, которая заменяет реальные значения в базе на похожие по формату, но фиктивные, сохраняя данные пригодными для тестирования, разработки и аналитики без раскрытия реальных людей и операций. Ниже — чем маскирование отличается от обезличивания персональных данных по 152-ФЗ, токенизации и шифрования, чем статическое маскирование отличается от динамического и на что смотреть при выборе решения; сравнение конкретных российских продуктов — на странице класса и на радаре маскирования.
Кратко
- Что это
- Техническая замена реальных значений в БД фиктивными с сохранением формата — не юридический термин 152-ФЗ.
- Vs обезличивание
- Обезличивание — правовой статус результата по 152-ФЗ и приказу РКН №140; маскирование — способ его достичь, но не гарантия.
- Vs токенизация
- Токенизация обычно обратима через отдельное защищённое хранилище токенов (vault), классическое маскирование — как правило нет.
- Два вида
- Статическое (SDM) — для копий тестовых сред; динамическое (DDM) — «на лету», по ролям, в продуктиве.
- Критично
- Сохранение формата и ссылочной целостности между таблицами, поддержка нужной СУБД — PostgreSQL, Oracle, MS SQL.
- Где сравнить вендоров
- Каталог маскирования и радар маскирования на SecRadar.
Что такое маскирование данных
Маскирование данных (data masking) — замена реальных значений в базе данных или тестовом наборе на структурно похожие, но фиктивные значения: номер карты выглядит как номер карты, ФИО — как ФИО, но восстановить по ним исходные данные без доступа к оригиналу или отдельному ключу нельзя либо это специально ограничено правами доступа.
Смысл — дать разработчикам, тестировщикам, подрядчикам и аналитикам данные, которые ведут себя как настоящие (проходят валидацию формата, сохраняют статистические свойства), но не раскрывают персональные данные, платёжную информацию или коммерческую тайну.
Термин используют в двух связанных, но не тождественных смыслах: как название класса технических средств — продукты, которые выполняют такую замену, — и как саму операцию, статическую или динамическую (раздел ниже). Запрос «маскирование данных в БД» обычно означает второе: как встроить такую замену в конкретную СУБД — PostgreSQL, Oracle, MS SQL Server и другие, разобрано в разделе критериев.
Маскирование vs обезличивание vs токенизация vs шифрование
Четыре термина в текстах о защите данных постоянно смешивают, хотя по механике и правовому статусу результата это разные операции.
Маскирование техника
Реальное значение заменяется фиктивным того же формата и типа. Обычно необратимо при статическом маскировании; при динамическом оригинал в БД не меняется вовсе, скрывается только результат запроса. Применение: тестовые среды, разработка, аналитика, экраны поддержки.
Обезличивание термин 152-ФЗ
Юридический статус результата: данные видоизменены так, что определить субъекта без дополнительной информации нельзя (п. 9 ч. 1 ст. 3 152-ФЗ). Формально может быть обратимым при методе «введение идентификаторов» с отдельно хранимым ключом. Применение: вывод данных из-под части требований 152-ФЗ при соблюдении методов приказа РКН №140.
Токенизация техника
Значение заменяется случайным сгенерированным токеном без смысловой связи с оригиналом; соответствие «токен — исходное значение» хранится отдельно, в защищённом хранилище (vault). Обратима — исходное значение восстанавливается через vault. Применение: платёжные данные, API и интеграции, где восстановление предусмотрено регламентом.
Шифрование техника
Данные преобразуются криптоалгоритмом с ключом и становятся нечитаемыми без ключа; формат обычно не сохраняется. Обратимо при наличии ключа. Применение: защита данных при хранении и передаче — не заменяет маскирование там, где нужны реалистичные, читаемые тестовые данные.
Ключевое разграничение: маскирование — техническая операция, обезличивание по 152-ФЗ — юридический статус её результата. Одно не гарантирует другое. Чтобы результат маскирования признавался обезличенными данными по закону, метод должен соответствовать перечню приказа Роскомнадзора №140 от 19.06.2025 — иначе замаскированные данные формально остаются персональными данными со всеми обязанностями по 152-ФЗ. Подробный разбор методов и правового статуса — в материале «Обезличивание персональных данных» на SecRadar.
Статическое (SDM) и динамическое (DDM) маскирование
Внутри самого маскирования есть два принципиально разных режима работы — выбор между ними определяется сценарием использования данных, а не тем, какой «лучше» в целом.
Замаскированная копия
Создаётся отдельная замаскированная копия базы: оригинал не меняется, копия используется в тестовой или dev-среде. Запросы к копии не требуют пересчёта на лету, скорость не страдает. Минус — копию нужно пересоздавать при изменении оригинала, и она занимает дополнительное место.
Маскирование «на лету»
Данные в базе остаются прежними, но результат запроса маскируется в реальном времени в зависимости от роли обратившегося: оператор поддержки видит частично скрытый номер карты, администратор БД — полное значение. Гибко для продуктива, но добавляет задержку на каждый запрос.
Практический ориентир: тестовые среды и разработку чаще закрывают статическим маскированием — копия предсказуема и не требует интеграции на уровне продуктивной СУБД. Продуктивные системы с разным уровнем доступа для разных ролей — колл-центр, аналитика, администрирование — чаще требуют динамического маскирования или комбинации обоих режимов.
Зачем нужно маскирование данных
Маскирование — один из технических способов реализовать обезличивание персональных данных, но результат признаётся обезличенным только при соответствии методам приказа РКН №140. Подробности — в материале об обезличивании ПДн.
Разработчики, QA и подрядчики не должны видеть реальные ПДн, платёжные данные или коммерческую тайну. Маскирование даёт реалистичные тестовые данные, которые сохраняют формат, длину полей и связи между таблицами — приложение работает корректно, а данные в нём вымышленные.
Для статистики, BI и обучения ML-моделей нужна аналитическая ценность данных, а не привязка к конкретному человеку. Маскирование убирает идентифицирующую часть, сохраняя структуру и распределение значений, пригодные для расчётов.
Критерии выбора решения
Ниже — на что смотреть у любого кандидата независимо от вендора; вес каждого критерия зависит от сценария (тестовая среда, продуктив, аналитика).
Формат и ссылочная целостность
Маска должна повторять формат исходного значения — длину, тип символов, при необходимости контрольную сумму (номера карт, СНИЛС). Одинаковое исходное значение должно маскироваться в одинаковый результат во всех связанных таблицах — иначе внешние ключи и JOIN ломаются, тестовая среда перестаёт быть рабочей.
Поддержка нужных СУБД
Проверяйте полный список поддерживаемых источников у конкретного продукта — PostgreSQL, Oracle, MS Sql Server остаются наиболее востребованными в российских ИТ-ландшафтах, но покрытие у разных вендоров сильно различается, особенно для отраслевых и самописных систем.
Необратимость vs обратимость
Для тестовых сред обычно нужна необратимая замена — оригинал там не требуется вовсе. Для аналитики с последующей контролируемой деанонимизацией по регламенту нужна обратимая схема, ближе к токенизации, с отдельным строгим контролем доступа к ключу или vault.
Производительность на больших БД
Для DDM критична задержка на каждый запрос — стоит замерять на реальном объёме и профиле нагрузки, а не на демо-стенде вендора. Для SDM — время полного цикла маскирования копии при росте объёма исходной базы.
Интеграция с DBF/DLP
Маскирование не заменяет защиту периметра БД или контроль исходящих каналов — это разные классы защиты, решающие смежные задачи. Уточняйте, есть ли готовые интеграции или API с DBF и DLP, если они уже есть в контуре.
Готовые правила для ПДн
Преднастроенные шаблоны распознавания и маскирования типовых категорий персональных данных — ФИО, СНИЛС, паспорт, номер карты, телефон — сокращают объём ручной настройки политик под каждую конкретную базу.
Сертификат ФСТЭК, где применимо
Для субъектов КИИ, госорганов и систем, где действуют требования сертификации СЗИ, статус сертификата конкретного продукта стоит сверять в госреестре СЗИ ФСТЭК. Для остальных сценариев формально не обязателен, но индикатор зрелости продукта.
On-premise развёртывание
Для чувствительных данных — ПДн, банковской тайны, гостайны — большинство сценариев требует локального развёртывания без передачи данных во внешние облака или SaaS-сервисы вендора.
TCO
Лицензия часто считается по числу или объёму защищаемых БД либо по числу полей политик. В стоимость владения закладывайте не только лицензию, но и внедрение, обучение команды и поддержку политик при изменении схемы БД.
Российские решения: что есть на рынке
Ниша решений, промаркированных именно как «маскирование данных», в России узкая и пока формируется — часть продуктов регистрируется под соседними классами (защита баз данных, средства защиты от НСД), а единого выделенного кода классификатора для маскирования в Реестре российского ПО нет. Из проверенных по первоисточникам примеров: «Гарда Маскирование» (реестр №15678, сертификат ФСТЭК №4718, действующий на дату проверки, — продукт из портфеля ООО «Гарда Технологии») выполняет классическое маскирование данных;
линейка «Damask» от АО «Дамаск Цифровая Безопасность» (резидент «Сколково», юрлицо зарегистрировано в 2024 году) включает продукт динамической токенизации данных при обращении к БД (реестр №30796) наравне с отдельным продуктом статического маскирования (реестр №30795) — оба внесены в реестр в 2025 году, действующего сертификата ФСТЭК на дату проверки у линейки не найдено.
Отдельно стоит «Крипто БД» (Аладдин Р.Д.) — прозрачное шифрование данных на уровне СУБД по ГОСТ 28147-89 / ГОСТ Р 34.12-2015 с функцией маскирования, отдельными SKU под конкретную СУБД (Oracle, MS SQL, PostgreSQL, Tibero); это функционально ближе к шифрованию, чем к маскированию в чистом виде, и сертифицирован ФСБ России как СКЗИ, а не ФСТЭК (номер сертификата ФСБ — по вторичным источникам, не проверен SecRadar по первоисточнику, помечено оценкой).
Это не полный перечень рынка и не рейтинг — актуальное сравнение продуктов по вендору, реестру, сертификату и покрытию функций смотрите на странице класса «Маскирование».
Частые ошибки при выборе маскирования данных
- Маскировать данные, не проверив ссылочную целостность между таблицами. Тестовая среда с «битыми» связями между таблицами бесполезна для QA — приложение падает на JOIN-запросах или показывает несогласованные данные.
- Путать техническое маскирование с юридическим обезличиванием по 152-ФЗ. Если метод не входит в перечень приказа РКН №140, данные формально остаются персональными данными несмотря на визуально изменённый вид.
- Использовать статическое маскирование там, где нужен ролевой доступ в продуктиве. Разовая замена копии не решает задачу разграничения по ролям — для этого нужен DDM.
- Не проверять производительность DDM на реальном объёме и пиковой нагрузке до внедрения. Задержка, незаметная на демо-стенде, может стать критичной под продуктивной нагрузкой.
- Хранить ключ или токен-хранилище без отдельного строгого контроля доступа при обратимой схеме. Обратимость без жёсткого разграничения доступа к ключу сводит на нет весь смысл защиты.
Чек-лист выбора решения по маскированию
- Определите сценарий: тестовая/dev-среда (обычно SDM), продуктив с ролевым доступом (обычно DDM) или аналитика — от этого зависит вес остальных критериев.
- Проверьте, требует ли задача юридического обезличивания по 152-ФЗ — тогда сверьте метод с перечнем приказа РКН №140, а не только с фактом визуального изменения данных.
- Составьте список СУБД и их версий, которые нужно покрыть, и сверьте с заявленной поддержкой у кандидата.
- Проверьте сохранение ссылочной целостности между связанными таблицами на своей, а не демонстрационной схеме данных.
- Определите, нужна ли обратимость — и если да, кто и как контролирует доступ к ключу или токен-хранилищу.
- Запросите нагрузочный тест на своём объёме данных, особенно для динамического маскирования в продуктиве.
- Уточните набор готовых правил для типовых категорий персональных данных и трудоёмкость настройки под нетиповые поля.
- Проверьте наличие интеграций с DBF/DLP, если они уже есть в контуре защиты.
- Для КИИ и госсектора — сверьте статус сертификата ФСТЭК конкретного продукта в госреестре СЗИ ФСТЭК.
- Посчитайте TCO на весь горизонт эксплуатации: лицензия, внедрение, обучение команды, поддержка политик при изменении схемы БД.
Где сравнить российские решения по маскированию
Критерии выше помогают сузить список кандидатов, но финальный выбор — это сравнение конкретных продуктов по вендору, статусу в реестре, сертификату и покрытию функций.
Маскирование — таблица сравнения
Вендор, реестр, статус сертификата ФСТЭК, покрытие функций — на проверяемых данных. Открыть каталог маскирования →
Маскирование — визуальная карта рынка
Позиции вендоров по возможностям, присутствию и комплаенсу на одной карте. Открыть радар маскирования →
Смежные классы, которые часто внедряют рядом с маскированием: DBF — защита периметра базы данных и аудит запросов, DLP — контроль каналов, которыми данные покидают периметр организации. Требования к персональным данным и обезличиванию разобраны в разделе «Персональные данные» на SecRadar, включая полный разбор обезличивания по 152-ФЗ.
Частые вопросы
Что такое маскирование данных?
Чем маскирование данных отличается от обезличивания персональных данных?
Что такое токенизация в контексте защиты данных?
Чем статическое маскирование (SDM) отличается от динамического (DDM)?
Нужен ли сертификат ФСТЭК для решения по маскированию данных?
Сравнить российские решения по маскированию
Каталог и радар SecRadar — вендор, реестр, статус сертификата ФСТЭК и покрытие функций на проверяемых данных, без пользовательских отзывов.