Я пытался найти хороший способ шифрования чувствительных столбцов в моей БД. Я думал, что встроенные механизмы шифрования SQL Server будут делать трюк, но либо я что-то упустил, либо сделал это неправильно.Шифрование столбцов SQL Server 2008
Первоначальный план состоял в том, чтобы создать таблицу с колонами, которые были зашифрованы симметричным ключом, и иметь представление, которое выбирает данные из таблицы, не зашифрованные. Однако мне не удалось выяснить, как использовать метод DecryptByKey в инструкции выбора вида. Кроме того, мне пришло в голову, что данные будут незашифрованными, перейдя в TO и FROM из представления, поэтому, если соединение не будет безопасным, это будет бесполезно.
Затем я решил принести все шифрование/дешифрование в мое приложение. Я полагал, что
Если БД была совершенно не в состоянии расшифровать свои собственные данные, а затем кто-то проникнуть в БД не смог бы сделать много на всех.
Это спасло бы сервер от попыток дешифрования/шифрования информации, поскольку шифрование/дешифрование в БД могло повлиять на производительность в глобальном масштабе, а не только на одной рабочей станции.
Так как он находится, мое приложение имеет «жестко закодированные» IV и Ключи для каждого столбца, который необходимо зашифровать. Он отправляет зашифрованную информацию в БД и получает зашифрованную информацию из БД. Это просто для того, чтобы возиться с вами, я знаю, что я должен поместить IV и ключи в другое место ... они просто не безопасны в коде приложения.
Я думал о этой бредовой идеи:
Клиентское приложение будет содержать один ключ и IV. Сервер будет содержать ключи/IV всех зашифрованных столбцов в одной таблице. Тем не менее, значения ключей/IV будут зашифрованы с помощью ключа/IV, который хранится в клиентском приложении.
При запуске клиентское приложение будет загружать все ключи/IV из БД в память и расшифровывать их по мере необходимости для просмотра данных, выбранных с сервера.
Также может быть отношение, которое присоединяется к пользователям с ключами, которые им разрешено использовать. Таким образом, приложение будет расшифровывать только те столбцы, которые пользователю разрешено видеть.
Считаете ли вы, что идея - победа или потеря? И как некоторые из вас реализовали шифрование с учетом сценария клиент-приложение/SQL Server?
Это действительно так? План заключался в шифровании чувствительных столбцов «только данных», таких как номера социального страхования, номера телефонов, номера кредитных карт и тому подобное. Столбцы, которые я обычно не индексировал. – instantmusic
Тогда хорошо., Вы просто сделали бы болью работать с данными. Как для отчетности. Лучше всего ИМХО по-прежнему обрабатывать безопасность на уровне приложений, защиту данных через сервер с TPM и предоставленные средства (то есть диск encryoption). – TomTom