Сочетание шифрования с динамической маскировкой данных

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

Я читал некоторые источники в Интернете и все еще немного запутался.

От Майкрософт:

"Динамическое маскирование данных дополняет другие функции безопасности SQL Server (аудит, шифрование, безопасность на уровне строк...), и настоятельно рекомендуется использовать эту функцию в сочетании с их в дополнение, чтобы лучше защитить конфиденциальные данные в базе данных"

https://stackoverflow.com/a/41769843/7435291

Необходимо руководство о том, как обе цели могут быть достигнуты.

Примечание. Хотел использовать динамическое маскирование данных из-за простоты настройки и независимости от другого уровня кода. Однако; не уверен в влиянии шифрования столбца


person needtoflow    schedule 21.05.2019    source источник
comment
Это действительно широкий вопрос с небольшим шансом на простой ответ. Для начала у вас должно быть четкое представление о том, кому разрешено просматривать данные и когда. Это нормально, если администраторы БД всегда могут расшифровать данные (поэтому допустимо только шифрование на стороне клиента)? А как насчет людей, которые получают резервную копию всего вашего сервера (данные в состоянии покоя)? Является ли ваша база данных многопользовательской, то есть у вас есть несколько клиентов, каждый из которых должен видеть только свои данные? Является ли соединение с самой БД небезопасным, поэтому вы всегда должны передавать данные в зашифрованном виде?   -  person Jeroen Mostert    schedule 21.05.2019
comment
Привет @JeroenMostert. У нас есть несколько типов пользователей, которые будут получать доступ к данным с веб-сайта. Однако; понятно, что для всех из них будут видны только замаскированные данные. Администратор dB должен иметь возможность просматривать расшифрованные данные; в некоторых редких случаях. Резервные копии принимаются через администратора dB. ИТ-специалисты, получившие резервную копию, не должны иметь возможности расшифровать исходные данные. У нас нет варианта использования с несколькими арендаторами в базе данных.   -  person needtoflow    schedule 21.05.2019
comment
Нужен ли конечным пользователям доступ к (их собственным) зашифрованным данным? Другими словами, нужен ли приложению веб-сайта доступ к расшифрованным данным, чтобы включить этот сценарий? Откуда исходно поступают данные — собирается ли само веб-приложение предоставлять их (в зашифрованном или незашифрованном виде)?   -  person Jeroen Mostert    schedule 21.05.2019
comment
Привет еще раз. Конечный пользователь увидит только замаскированную версию данных на веб-сайте независимо от разрешения. Данные изначально поступают из форм на Веб-сайте, которые заполняются авторизованными пользователями. Его необходимо хранить в бэкенде в зашифрованном виде и в дальнейшем отображать в замаскированном формате на Веб-сайте.   -  person needtoflow    schedule 21.05.2019