Шифрование в SQL действительно полезно только для защиты данных, поскольку они хранятся на сервере, хотя это не означает, что они не важны.Когда вы упоминаете, что основной проблемой являются инъекционные атаки или тому подобное, меня беспокоит, будет ли база данных использовать одну учетную запись (SQL или иным образом) для подключения к базе данных, что будет обычным явлением для общедоступного интернет-сайта.Если вы используете встроенную аутентификацию или подключаетесь к SQL с использованием тех же учетных данных, которые предоставляются приложению, то шифрование SQL может работать нормально.
Однако, если вы используете один логин, шифрование SQL будет управлять шифрованиеми расшифровывать данные для вас на основе вашего логина.Таким образом, если ваше приложение скомпрометировано, SQL может быть не в состоянии защитить эти данные для вас, поскольку он неявно расшифровывает их и не знает, что что-то не так.
Возможно, вы захотите, как вы предложили, зашифровать/ расшифровать данные в приложении и сохранить в виде байтов в базе данных.Таким образом, вы контролируете, кто может дешифровать данные и когда (например, вы можете назначить ключ для дешифрования этих данных тем немногим сотрудникам, о которых вы упомянули, и которые играют определенную роль).Вы можете заглянуть в Microsoft Security Application Block или Bouncy Castle и т. Д., Чтобы найти хорошие утилиты шифрования.Просто будьте осторожны с тем, как вы управляете ключом.
Обновление :
Хотя вы могли бы потенциально использовать две строки подключения: одну обычную, без прав на зашифрованные данные,и тот, который имеет ключ и права на данные.Затем пусть ваше приложение использует соответствующее соединение, когда у пользователя есть права.Конечно, это довольно глупо.