Несколько месяцев назад у меня была похожая ситуация.В таблице, содержащей личные данные, некоторые столбцы должны быть зашифрованы, но эта таблица используется в унаследованном приложении и имеет много ссылок.
Итак, вы можете создать отдельную таблицу для хранения зашифрованных данных:
CREATE TABLE [dbo].[Customer_data_encrypted]
(
[customer_id] PRIMARY KEY -- you can create foreign key to the original one, too
,[name] VARBANRY(..)
,[cretit_card_numbe] VARBINARY(..)
);
Затем создать INSTEAD OF INSERT UPDATE DELETE
триггер на исходной таблице. Логикав триггере все просто:
- при удалении, удаление из обеих таблиц
- при обновлении / вставке - шифрование данных и вставка в новую таблицу;использовать какую-то маску для исходной таблицы (например,
***
или 43-****-****-****
)
Затем выполните первоначальную миграцию, чтобы переместить данные из исходной таблицы в новую, а затем замаскироватьit.
Выполнение описанных выше шагов приятно, потому что:
- каждая вставка / обновление исходной таблицы продолжает работать
- Вы можете создать триггер с помощью
EXECUTE AS OWNER
чтобы иметь доступ к симметричным ключам и вносить изменения непосредственно в оператор T-SQL, не открывая сертификаты, или пользователями, которые не имеют к ним доступа - во всех ссылках чтения, вы собираетесь получить данные маскиТаким образом, вы не беспокоитесь о критическом взломе приложения
- . Наличие триггера дает вам возможность легко создавать и изменять информацию
Это зависит от вашей среды и потребностей бизнеса, поскольку для одного изТаблицы Я сохранил зашифрованное значение в виде нового столбца, а не отдельной таблицы.Итак, выберите то, что вам больше подходит.