Вся безопасность на самом деле заключается в повышении планки и компромиссов юзабилити. С шифрованием здесь есть много вариантов, но на самом деле все сводится к управлению ключами.
У кого есть ключи для расшифровки?
Как они хранятся?
Атаки с применением грубой силы на данные вашего приложения (скажем, они захватывают ленту резервных копий зашифрованной базы данных SQL Server путем перехвата FedEx в Iron Mountain) реже, чем внутренняя атака на систему управления ключами, например сотрудник или разработчик изменяет программу для расшифровки и вывода данных.
Поскольку приложение, вероятно, в общем случае должно дешифровать эти данные в любое время авторизованным пользователям, я бы, вероятно, сосредоточился на видимости чувствительных столбцов и ролях, которым разрешен доступ к ним, а затем позаботился о шифровании.
SQL Server предлагает только прозрачное шифрование данных и шифрование соединений. Это бесполезно, если у пользователей есть SELECT *
доступ к таблице. Самостоятельное шифрование в столбце без ведома SQL Server может быть проблематичным. Например, если один столбец является платными данными и является конфиденциальным, если вы зашифруете его в столбце, вы не сможете просто запустить SELECT Employee, SUM(Pay) GROUP BY Employee
Итак, сначала я хотел бы убедиться, что вы определили пользователей и роли в вашем приложении, проанализировать, какой у них доступ, и убедиться, что все соединения с базой данных используют соответствующие роли.