В современной цифровой экономике данные принято называть новой «нефтью», и если подумать, то это не просто топливо для экономики, но и горючая сущность: необработанные персональные данные (ПДн) являются токсичным и взрывоопасным активом. С одной стороны, для команд разработки, тестирования и аналитики «сырые» данные – это жизненно необходимое топливо (этим специалистам требуются реалистичные профили клиентов, истории транзакций и сложные взаимосвязи для обеспечения качества программного обеспечения) в зонах разработки. С другой же стороны, для ИБ-специалистов эти же данные представляют собой территорию максимального риска, требующую изоляции в «крепости» продуктивного контура. Долгое время индустрия жила в парадигме компромисса, где безопасность приносилась в жертву скорости, а практика копирования реальных продуктивных баз данных (Production) в среды разработки и тестирования (Test/Dev) стала негласным стандартом. И появился «теневой ландшафт» данных (наподобие теневого ИТ), неконтролируемые копии чувствительной информации, разбросанные по серверам разработчиков, ноутбукам аналитиков и облачным стендам подрядчиков.
В текущей статье мы разберем тему маскирования данных, технологию, которая позволяет найти не просто компромисс, а довести ситуацию до win-win состояния. В Российской Федерации также были введены оборотные штрафы за утечки данных и вступили в силу новые нормативные акты Роскомнадзора. Все это повысило актуальность темы и её значимость для бизнеса.
Традиционная модель кибербезопасности часто напоминает средневековый замок: высокие стены и глубокий ров вокруг «сокровищницы» (продуктивной базы данных). Однако среды разработки и тестирования (Dev/Test) в этой аналогии часто играют роль плохо охраняемой боковой калитки для прислуги (и это подтверждается статистикой, ведь до 70% рисков утечки чувствительной информации сосредоточено именно в непроизводственных системах). На каждую защищенную продуктивную базу данных приходится в среднем от 8 до 10 её копий в тестовых, девелоперских, аналитических и песочных средах. Эти копии часто содержат те же самые реальные ПДн (ФИО, паспорта, транзакции), но находятся в условиях значительно меньшего контроля и защиты.
Атаки на цепочку поставок тоже занимают всё больший процент по той же причине:
- В январе 2024 года группировка Midnight Blizzard скомпрометировала корпоративную переписку руководства Microsoft. Точкой входа стал устаревший тестовый тенант, учётная запись в «песочнице» не была защищена многофакторной аутентификацией (MFA), так как система считалась некритичной. Хакеры использовали метод перебора паролей, закрепились в тестовой среде, а затем, используя избыточные права, совершили горизонтальное перемещение в основную корпоративную сеть.
- Компания Uber дважды наступала на одни и те же грабли: в 2016 году хакеры нашли ключи доступа к AWS в приватном репозитории GitHub, который использовался инженерами (это позволило скачать данные 57 миллионов пользователей), а в 2022-ом – атака повторилась через компрометацию учетных данных подрядчика, имевшего доступ к внутренним инструментам разработки.
- В России наблюдается всплеск утечек через «забытые» базы, ряд крупных утечек (ритейл, логистика, медицина в 2024-2025 годах) произошел из-за того, что разработчики выкладывали дампы баз данных на временно арендованные облачные серверы для тестирования, забывая закрыть порты или установить пароль. Поисковые системы (Shodan, Censys) индексировали эти открытые Elasticsearch или MongoDB инстансы за считанные часы.
В итоге мы видим, что данные, используемые в разработке (ключи, дампы), часто хранятся небрежно, становясь легкой добычей, а тестовая среда без защиты – трамплин для атаки на ядро бизнеса. Маскирование данных – это создание версии базы данных, которая выглядит и ведет себя как настоящая, но не содержит реальных секретов.
Это фейк высокого качества, или дублёр в кино. Представьте съемки опасного трюка в блокбастере с голливудской звездой первой величины (реальные данные), чьё лицо знают все, её здоровье застраховано на миллионы. Рисковать звездой нельзя, а в фильме есть сцена взрыва или падения с крыши (Тестовая среда). Тогда маскированием будет использование профессионального каскадера-дублера: он одет в тот же костюм, имеет тот же рост и телосложение (сохранение формата). На общем плане (в приложении) зритель не заметит подмены. Но если на съемках произойдет несчастный случай (утечка), пострадает дублер, а «звезда» (реальный клиент) останется в безопасности.
Теперь давайте разберёмся, как это работает, выделив 2 подхода:
1) Статическое маскирование (Static Data Masking, SDM), или «Золотая копия для разработчиков» – это процесс создания необратимо обезличенной копии базы данных до того, как она попадет в тестовую среду. Для начала создается клон продуктивной базы (Snapshot) в изолированной зоне (Staging), затем запускается скрипт маскирования, который перезаписывает чувствительные данные, а оригинал в клоне уничтожается. «Чистая» копия передается разработчикам, и такой подход обеспечивает максимальную безопасность т.к. в ней физически нет реальных данных. Статических подход часто применяется в разработке, функциональном тестировании, обучении AI/ML и для передачи данных аутсорсерам.
2) Динамическое маскирование (Dynamic Data Masking, DDM) или «Фильтр восприятия для операторов» работает иначе: данные в базе остаются настоящими и неизменными, а маскирование происходит «на лету» в момент запроса (SQL Query), как при анализе трафика правилами корреляций в SIEM-системах, поиске аномалий в UEBA и анализе угроз в TIP. Между пользователем и данными стоит прокси-шлюз или механизм СУБД: если данные запрашивает Администратор, он видит всё, оператор колл-центра видит **** вместо номера карты, а техподдержка, BI-отчеты будут видеть только данные, важные для текущей задачи. Такой подход защищает от любопытства инсайдера, но не от прямого взлома файла базы данных
Представьте, как спецслужбы рассекречивают архивный документ: перед тем как отдать его историкам (разработчикам), офицер делает ксерокопию, черным маркером замазывает настоящие имена агентов и вписывает сверху вымышленные. Историки получают документ, с которым можно работать, но узнать реальных агентов невозможно, даже если украсть этот листок. Так и работает маскирование.
Его также можно переопределить разными методиками:
а) Замена значения на другое из заранее подготовленного справочника. Это требует обширных словарей (тысячи имен, городов), чтобы избежать неестественных повторений. Работает это как актёрский или писательский псевдоним: человек тот же, но в титрах другое имя.
б) Перемешивание или перестановка реальных значений внутри колонки. Система берет колонку «Зарплата» всех сотрудников и случайным образом меняет значения местами. Так сохраняется статистическая достоверность (сумма, среднее, распределение), что критично для финансовой аналитики, но на малых выборках это небезопасно: если в отделе только Директор и Стажер, поменяв их зарплаты местами, легко вычислить правду. Это как перетасовка колоды карт: карты те же самые, но теперь они у других игроков.
в) Обнуление или усечение, когда происходит замена данных на NULL или маску. Так поля, не критичные для тестов можно маскировать быстро, или когда нужно скрыть часть информации (PAN карты).
г) Детерминированное маскирование, самый сложный и важный метод для интеграционного тестирования. В микросервисной архитектуре данные о клиенте размазаны по разным базам (CRM, Биллинг, Логистика), и если маскировать их случайно, связи (Foreign Keys) разорвутся, поэтому система маскирования использует алгоритм, который при одном и том же входе всегда дает одинаковый выход, используя секретную «соль».
В завершение обзора приведем пример работы postgresql_anonymizer: проведём маскирование таблицы клиентов для разработчиков.
1) Подключение расширения:
CREATE EXTENSION IF NOT EXISTS anon CASCADE;
SELECT anon.init();
2) Объявление стратегии маскирования (декларативный подход), заменяем фамилии на случайные значения из словаря (Метод Замены):
SECURITY LABEL FOR anon ON COLUMN clients.lastname
IS 'MASKED WITH FUNCTION anon.fake_last_name()';
3) Генерируем псевдо-email на основе ID, это гарантирует, что user_id=5 всегда получит один и тот же email:
SECURITY LABEL FOR anon ON COLUMN clients.email
IS 'MASKED WITH FUNCTION anon.pseudo_email(clients.id)';
4) Паспортные данные удаляем полностью (Метод Изменения состава)
SECURITY LABEL FOR anon ON COLUMN clients.passport_num
IS 'MASKED WITH VALUE NULL';
5) Для телефонных номеров оставляем код региона, скрываем остальное (Частичное маскирование)
SECURITY LABEL FOR anon ON COLUMN clients.phone
IS 'MASKED WITH FUNCTION anon.partial(phone, 2, ''*******'', 2)';
6) Процесс обезличивания (In-Place Anonymization) запускается на копии базы:
SELECT anon.anonymize_database();
В итоге, если раньше у нас была строка: Иванов / ivanov@mail.ru / 4500 / 123456, +79031234567, то после будет примерно так: Смит / user_84@example.com / NULL/ +7*******67.
Технология маскирования данных – это единственный зрелый ответ на задачу нахождения баланса между безопасностью и быстрой разработкой. Переходя от копирования к обезличиванию, компании создают «цифровую песочницу», где разработчики могут безопасно строить замки, ломать стены и экспериментировать, не рискуя обрушить реальный бизнес.
В эпоху цифровой прозрачности и жесткого регулирования (152-ФЗ, Приказ № 140) использование «сырых» данных в тестировании становится недопустимым: тестовые среды, наполненные реальными персональными данными, превратились в токсичные и взрывоопасные активы, способные потопить бизнес под тяжестью оборотных штрафов. Но внедрение статического, детерминированного маскирования в CI/CD конвейер – это не просто соблюдение закона. Это стратегическое преимущество, позволяющее быть быстрее, гибче и безопаснее конкурентов.
 2 - копия.jpg)
