Always Encrypted существует для решения не только проблемы, связанной с проверкой шифрования данных при передаче. На самом деле, это даже не главная проблема, которую решает Always Encrypted.
Большая проблема, которую решает Always Encrypted, заключается в том, что с прозрачным шифрованием данных (TDE), ключи и сертификаты, которые защищают зашифрованные данные, сами хранятся в базе данных. Это может быть проблемой для кого-то, учитывая поместить свою базу данных SQL Server в облако, потому что у облачного провайдера в конечном итоге есть секреты для расшифровки данных.
При использовании Always Encrypted ключ шифрования столбца (CEK), который используется для шифрования / дешифрования данных столбца, хранится в базе данных в зашифрованном виде. Но вот что важно: ключ, используемый для шифрования / дешифрования CEK, хранится вне базы данных , , поэтому база данных не может самостоятельно расшифровать данные.
Все, что может сделать база данных, это
- Укажите зашифрованный CEK,
- укажите местоположение CMK, а
- обслуживать / хранить предварительно зашифрованные данные.
Клиент должен получить главный ключ столбца (CMK) из хранилища ключей / сертификатов, где бы он ни находился, затем использовать CMK для расшифровки CEK и использовать расшифрованный CEK для шифрования / дешифрования данных.
Так что это концептуальная разница. Вот пара страниц, которые вдавались в детали:
Да, и Always Encrypted имеет ряд существенных недостатков в отношении запросов данных и других вещей. Если вам это интересно, эта статья дает довольно хороший список ограничений.