Привет, Хабр!

На связи Артемий Новожилов, архитектор систем ИБ и автор ТГ-канала Data Security и Дмитрий Ларин, руководитель продуктового направления по защите баз данных, группа компаний «Гарда». С нами вы могли познакомиться по таким статьям как маскирование и Apache Kafka. И сегодня мы хотим продолжить тему маскирования данных.

Современные компании обрабатывают огромные объемы конфиденциальных данных: персональные данные (как сотрудников, так и партнеров и клиентов), информацию о клиентах и их заказах, финансовые и бухгалтерские сведения, данные, относящиеся к коммерческой тайне и интеллектуальной собственности, а также технические настройки и доступы. В связи с этим возникают повышенные риски утечки данных, сложности с соблюдением требований законодательства (например, ФЗ-152 и GDPR), угроза инсайдерских атак, а для тестов или аналитики приходится создавать отдельные копии баз данных (БД).

Один из эффективных способов защиты данных – динамическое маскирование (Dynamic Data Masking, DDM). Технология позволяет скрывать или искажать конфиденциальные данные в реальном времени в зависимости от ролей и прав доступа пользователя, не изменяя их в базе данных. Это снижает риск утечки информации при работе с базами данных упрощает соблюдение требований законодательства и позволяет безопасно использовать данные в тестовой среде или при аналитике, не раскрывая их реальное содержимое. В отличие от статического подхода, динамическое маскирование не требует создания отдельных копий данных, что экономит ресурсы и позволяет не менять бизнес-процессы.

В этой статье разберем:

• Что такое динамическое маскирование и зачем оно нужно

• Основные сценарии применения

• Технические реализации в базах данных и приложениях

• Примеры настройки в наложенном средстве защиты

Что же такое динамическое маскирование?

Чтобы безопасно работать с конфиденциальной информацией, придумали способы ее маскировать. Преимущества метода:

• обеспечение соответствия требованиям регуляторов при обработке информации (ФЗ-152 «О защите персональных данных», GDPR и подобных актов);

• безопасное использование БД сотрудниками и внешними подрядчиками, снижение риска утечек персональной информации;

• специализированные инструменты для маскирования часто поддерживают планирование задач и интеграцию в CI/CD-процессы, позволяя контролировать нагрузку на продуктивную базу и не мешая основным бизнес-процессам.

Существует два типа маскирования баз данных.

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

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

Главное отличие между методами – динамическое маскирование «на лету» меняет данные в ответе, который получает пользователь, статическое – создает копию production базы данных с сохранением ее структуры и взаимосвязей, но с заменой конфиденциальных данных на синтетические. При этом статическое маскирование может изменять только часть данных (например, заменяя реальные email на user1@example.com) или создавать урезанную копию исходной БД. Важно то, что при статическом маскировании процесс обезличивания, обычно, необратим.

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

Сценарии применения динамического маскирования

1. Разграничение доступа по ролям. Менеджер видит все детали клиента, а оператор колл-центра – только часть (например, скрыты данные паспорта, адрес или номер банковской карты). Руководители видят суммы контрактов, а сотрудники без финансового допуска – маскированные значения. Маскирование включается при доступе из внешней сети или через VPN при удаленной работе.

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

3. Интеграция с BI-системами. Обезличивание чувствительных данных «на лету» при передаче в аналитические панели.

4. Защита данных в CRM, ERP, HRM-системах. В CRM скрываются контактные данные клиентов от рядовых сотрудников. В ERP отображаются маскированные зарплаты или финансовые отчеты в зависимости от уровня доступа.

5. Внешний аудит и демонстрации. Внешним аудиторам или проверяющим предоставляется доступ к системе с динамически обезличенными данными, без риска утечки.

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

7. Облачные и мультиарендные среды. Разные клиенты или арендаторы в облаке и в SaaS-решениях видят только свои данные, остальное скрывается или маскируется.

8. Обеспечение нулевого знания (zero knowledge). Даже системные администраторы и разработчики, имеющие доступ к БД, не могут видеть реальные персональные данные.

9. Защита в API и микросервисах. При вызовах API чувствительные поля маскируются в ответах в зависимости от токена доступа или контекста запроса.

10. Встраивание в CI/CD. Когда в процессах CI/CD задействуются реальные данные (например, при автотестах или нагрузочном тестировании), возникает риск непреднамеренного раскрытия конфиденциальной информации. Чтобы этого избежать, можно встроить динамическое маскирование данных на этапе работы с продуктивной или тестовой БД.

11. Обучение персонала. Новые сотрудники могут проходить обучение на продуктивной системе, не получая доступ к реальным данным.

Техническая реализация маскирования в СУБД и приложениях

Динамическое маскирование можно реализовать как собственными средствами в СУБД, так и через middleware-приложения. Рассмотрим основные принципы технической реализации.

Встроенные механизмы в СУБД

Многие современные СУБД поддерживают нативное динамическое маскирование данных на уровне самой базы. Это позволяет задать как именно данные будут отображаться пользователю в зависимости от его роли или условий запроса.

Примеры реализации в популярных СУБД.

Microsoft SQL Server

• Функция: Dynamic Data Masking

• Маскирование задается на уровне столбцов:

sql
CopyEdit
ALTER TABLE Customers  
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

Пользователи без специального разрешения видят, например: aXXX@XXXX.com

Oracle Database

• Использует Virtual Private Database (VPD) и Data Redaction

• Маскирование на уровне политики: можно задать, какие данные и кому отображать

PostgreSQL

• Нативно не поддерживает маскирование, но реализуется через VIEW с логикой маскирования, Row-Level Security (RLS) и функции для подмены данных

MySQL

• Маскирование реализуется через триггеры, представления (VIEW) или сторонние расширения

Реализация в приложениях (middleware-уровень)

Когда маскирование невозможно или неудобно сделать на уровне базы, его реализуют на уровне промежуточного слоя – между приложением и БД. Подходы:

• Прокси/шлюз перед базой данных, который перехватывает SQL-запросы и переписывает ответы

• Маскирование в API – перед возвратом данных клиенту происходит подмена чувствительных значений

Политики маскирования и контроль доступа

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

Сравнение подходов

Итого, технически динамическое маскирование реализуется:

• встроенными средствами СУБД (маскирование колонок, редактирование представлений);

• через прокси, API, middleware-приложения;

• специализированными продуктами для маскирования

• гибридно: БД + приложение + контроль доступа

Сравним первые три подхода к динамическому маскированию, так как четвертый – комбинирует критерии из трех базовых, поэтому его вынесли за скобки.

Как динамическое маскирование работает в «Гарда DBF»

Мы реализовали функционал динамического маскирования, как модуль «Гарда DBF» – продукте для защиты баз данных класса Database activity monitoring (DAM)/Database Firewall (DBF). Важная ремарка: для его работы необходимо, чтобы «Гарда DBF» был установлен по принципу L3 Reverse proxy, то есть «в разрыв», когда сессия заворачивается на сенсор продукта.
Правила маскирования задаются в формате JSON. Так, например, список пользователей, для которых не нужно применять маскирование будет выглядеть так:

“masking_whitelist”: [
 “postgres”
]

Чтобы уметь работать с белыми списками, необходимо научить программный комплекс (или его отдельные модули) получать пользователя из протокола взаимодействия с БД. Важно отметить, что протокол и способы работы с ним для разных БД может отличаться.

Пожалуй, главными вопросами при настройке динамического маскирования будут: кому разрешено видеть данные и какие именно?

На первый вопрос отвечают белые списки: в конфигураторе «Гарда DBF» существует конечный список пользователей, которым разрешено видеть конфиденциальные данные (номер телефона, адрес фактического проживания, номер карты и другие).

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

“masking_regex”: {
 “name”: {
  “regex”: [A-Z][a-z]”,
  “mask_mode”: “inner”
  …
 }
}

“mask_mode”: “inner” – означает маскировать внутри строки, подходящий под регулярное выражение. Например:

Исходное Результат

Alice  li*

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

Заключение

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

Мы показали, как технология реализуется в «Гарда DBF» – через маскирование на уровне сетевого трафика, без изменения самих данных. Используются правила в формате JSON, поддерживается работа с raw-ответами и регулярными выражениями. Такой подход позволяет централизованно управлять доступом к данным. В итоге можно гибко настраивать маскирование под разные сценарии и типы пользователей.