Маскирование данных – это дисциплина

Пока копии не обезличены, безопасность баз данных не может считаться полной

Источником большинства серьезных инцидентов, связанных с утечками, оказываются не продуктивные системы, а копии их данных. Они создаются для самых разных задач: от поддержки подрядчиками и интеграции с внешними сервисами до миграции и тестового запуска новых продуктов. В продуктивной среде компании выстраивают сложную систему защиты: от строгих политик доступа до постоянного мониторинга. Но как только данные выходят за пределы этого контура, уровень контроля снижается, и именно в этот момент вероятность утечки многократно возрастает. Типовым решением становится маскирование данных, позволяющее обеспечить предсказуемую и повторяемую защиту на уровне самой СУБД.

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

Даже организации, которые используют только готовые продукты и полагаются на подрядчиков, все равно передают данные за пределы своего периметра. Если эти данные уходят «как есть», они могут оказаться в руках десятков людей, мягко говоря, не связанных жесткими обязательствами по их защите. Маскирование позволяет избежать такого сценария – данные передаются подрядчикам, сохраняется их ценность, например, для анализа, но исключается риск раскрытия персональной информации.

В случае PostgreSQL этот процесс можно выстроить средствами pg_anon*: инструмент формирует дампы, где данные сразу преобразованы по заданным правилам, и на целевой стороне оказывается уже безопасная база. Pg_anon разработан и развивается компанией «Тантор Лабс» (входит в «Группу Астра») для PostgreSQL и совместимых с ней СУБД.

Методы маскирования и их особенности

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

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

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

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

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

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

Практика применения

Практическая сторона маскирования предполагает согласованную работу нескольких блоков. Подразделение информационной безопасности формирует требования, определяет перечень данных, подлежащих обезличиванию, и закрепляет политику в документах. ИТ-служба или подрядчики обеспечивают техническую реализацию, выбирают инструмент, настраивают шаблоны и контролируют процесс передачи данных. Бизнес-подразделения, в свою очередь, уточняют, какие данные должны оставаться пригодными для аналитики и отчетности, чтобы маскирование не снижало их ценность.

Основная трудность заключается в сопротивлении со стороны интеграторов и подрядчиков. Им удобнее работать с «боевой» базой, чем тратить ресурсы на настройку обезличивания. Поэтому маскирование должно быть не просто рекомендацией, а обязательным условием в договорах и регламентах.

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

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

Третья – аналитика и «пилоты». Бизнесу нужны данные для исследований и проверки гипотез, но использование реальных персональных данных создает неприемлемый риск. Если анализировать отчеты на исходных данных, всегда есть вероятность случайного раскрытия информации. Маскирование позволяет сохранить статистическую ценность, убрав возможность идентификации.

Pg_anon встроен именно в эти сценарии: маскирование происходит на этапе создания дампа, и у подрядчика или аналитической команды оказывается уже безопасная копия. При этом pg_anon поддерживает параллельную обработку и регулировку нагрузки на СУБД. Дамп сохраняется в сжатом формате, поэтому дополнительное архивирование не требуется, а восстановление базы в целевой системе можно ускорить за счет упрощенных настроек инициализации.

Однако ни один инструмент не решает всех задач одинаково хорошо. Коммерческие продукты предоставляют широкий функционал, SLA и поддержку, но требуют серьезных бюджетов. Если компания полагается только на такие решения, она рискует столкнуться с высокой стоимостью владения и зависимостью от вендора. Российский коммерческий софт, как правило, адаптирован под требования 152-ФЗ и способен интегрироваться с DLP и другими локальными системами.

С другой стороны, Open Source-инструменты гибки и доступны, но требуют компетенций и не дают формальных гарантий. Использование их без подготовки может обернуться тем, что настройка затянется, а критичный проект останется без защиты.

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

Отдельно стоит отметить, что коммерческая версия pg_anon в составе платформы Tantor имеет графический интерфейс. Многие операции, которые в бесплатном варианте требуют ручной работы с консолью и словарями, становятся заметно более удобными через UI. Это полезно, если времени или других ресурсов на настройку CLI нет, но задача встроить маскирование в стандартные процессы работы с СУБД при этом стоит.

Заключение

По данным Gartner, к 2026 г. более 70% крупных организаций будут использовать технологии маскирования данных в тех или иных формах. В России статистика не такая впечатляющая: согласно опросу, проведенному «Ассоциацией специалистов по защите информации» в 2024 г., лишь около четверти компаний системно применяли маскирование. Причем большинство ограничивается разовыми мерами в рамках внедрения новых систем.

Тем не менее, маскирование перестает быть второстепенным инструментом и становится частью обязательной практики работы с базами данных. Копии – слабое место любой инфраструктуры, и именно там нужна защита, которая встроена в процесс и не зависит от человеческого фактора. Иначе каждая копия превращается в потенциальный источник утечки.

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

/ Сноски /

* https://github.com/TantorLabs/pg_anon

Статью подготовил Алексей Кулаков, директор департамента развития продуктов «Тантор Лабс».