Динамическое маскирование данных — что это, чем оно не является и как использовать его эффективно

Автор: Madhumita Tripathy MSFT, Dynamic Data Masking – What it is, What it isn’t, and How to use it effectively

В этой статье мы объясним основное назначение функции динамического маскирования данных: Dynamic Data Masking (для упрощения разработки приложений), разберём как она работает и её надлежащие сценарии использования, а также её ограничения. Если вы рассматриваете возможность использования динамического маскирования данных (DDM) или пересматриваете свою стратегию защиты данных, эта информация поможет вам принять обоснованные решения.

Для чего предназначено динамическое маскирование данных

Динамическое маскирование данных было представлено в SQL Server 2016 как встроенный метод маскирования конфиденциальных данных в результатах запросов. DDM перехватывает результаты запроса до того, как они покинут ядро базы данных, и заменяет определённые фрагменты данных маскированным представлением. Например, с помощью DDM вы можете настроить так, чтобы любой запрос к столбцу email возвращал значения вида jXXX@XXXX.com вместо настоящего адреса электронной почты — без изменения хранимых данных. Функция была разработана, чтобы упростить работу разработчика приложений: если вам нужно скрыть или обфусцировать данные ради приватности, вы можете делать это централизованно и декларативно в базе данных, а не писать пользовательский код в каждом приложении.

По сути, с DDM правила маскирования определяются один раз в базе данных и автоматически применяются к результатам запросов для непривилегированных пользователей. Это устраняет необходимость дублировать логику маскирования в приложениях и отчётах. По умолчанию разработчики и аналитики видят маскированные данные, что помогает предотвращать случайное или небрежное раскрытие конфиденциальной информации, а значит, предотвращает утечки из-за «подглядывания через плечо».

Чем DDM отличается от других функций безопасности

Динамическое маскирование данных влияет только на то, что пользователи видят в результатах запросов — оно не защищает сами данные. В отличие от шифрования (Always Encrypted) или безопасности на уровне строк (Row-Level Security), DDM не шифрует данные, не фильтрует строки и не отменяет разрешения SQL. Пользователи с повышенными привилегиями (например, UNMASK, db_owner или sysadmin) всегда видят немаскированные данные и могут изменять или удалять правила маскирования.

От чего DDM не защищает

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

• Логические выводы и логика запросов. Настойчивый пользователь с доступом к базе данных часто может вывести маскированные данные, эксплуатируя условия запросов. Любознательный пользователь может выполнить серию запросов, постепенно сужая диапазон, пока не определит конкретное значение или диапазон для определённого столбца. База данных всё ещё сравнивает настоящие значения под капотом, поэтому такие запросы работают. Важно отметить, что это не ошибка; это ожидаемое поведение, обусловленное дизайном DDM.
• Пользователи с дополнительными разрешениями. Если пользователю удастся получить более высокие привилегии, например возможность изменять схемы таблиц, он сможет напрямую отключить или удалить маскирование. Поэтому критически важно контролировать и проверять, кто обладает такими привилегиями.
• Раскрытие метаданных. Правила маскирования и маскированные столбцы обнаруживаются через системные метаданные.
• Перемещение или копирование данных. Динамическое маскирование — это не свойство самих данных; это свойство схемы таблицы в конкретной базе данных. Резервные копии, копии или экспорты могут раскрывать немаскированные данные в зависимости от разрешений.

Надлежащее использование и лучшие практики DDM

Учитывая такое поведение по дизайну, как следует эффективно использовать динамическое маскирование данных? Вот рекомендации:

• Используйте DDM для сокращения усилий на разработку. Применяйте DDM, когда цель — уменьшить сложность разработки, повысить согласованность между приложениями и обеспечить более чистый пользовательский опыт.
• Сочетайте DDM с другими функциями. Динамическое маскирование данных лучше всего работает как один из слоёв защиты в стратегии «эшелонированной обороны». Например, если у вас есть безопасность на уровне строк, внедрение DDM может добавить дополнительный уровень конфиденциальности, маскируя столбцы в пределах разрешённых строк.
• Жёстко контролируйте привилегированный доступ. Уделяйте пристальное внимание тем, у кого есть роли вроде db_owner, sysadmin или разрешения CONTROL на базу данных. Также проверяйте, у кого есть возможность запрашивать маскированные столбцы и изменять схемы или маски.
• Обучайте пользователей и заинтересованных лиц. Убедитесь, что все в вашей организации, кто разрабатывает решения по безопасности или соответствию требованиям, понимают природу DDM. Она может вводить в заблуждение, если её не понимать.
• Отслеживайте злоупотребления. Внедрите аудит на ваших маскированных таблицах и столбцах, чтобы ловить попытки обойти DDM и реагировать на них.
• Тестируйте конфигурации маскирования. В непроизводственной среде проведите тесты собственной реализации и проверьте результаты.

Заключение

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