Каков наилучший способ сохранить пароль в SQL Server 2008? - PullRequest
1 голос
/ 12 января 2010

Я планирую сохранить конфиденциальную информацию клиента с помощью сертификата SQL Server / (a) симметричных ключей. Хотя сейчас данные в безопасности, сертификат и ключи не читаются, мне интересно, куда мне положить ключи? Есть ли лучшие практики? Единственное, о чем я мог подумать, это создать таблицу, доступную только для dbo или выделенного логина, и сохранить ее там. Пожалуйста, дайте мне ваши ценные советы.

Спасибо, Эбе.

Ответы [ 3 ]

1 голос
/ 13 января 2010

Сертификаты могут быть зашифрованы главным ключом базы данных, а главный ключ базы данных может быть зашифрован главным ключом сервера. Главный ключ сервера шифруется с использованием DPAPI с ключом машины и / или ключом учетной записи. Это все объясняется в Иерархии Шифрования .

Автоматизированная служба, которой требуется доступ к секретам зашифрованных данных, может опираться на эту иерархию шифрования. Данные защищаются во время выполнения с использованием обычной защиты доступа (списки контроля доступа и разрешения / запрещение / отзыв разрешений для SELECT), шифрование добавляется только для обеспечения случайной защиты от несанкционированного доступа к среде. Защита от случайного несанкционированного доступа к мультимедиа в конечном счете зависит от пароля учетной записи службы и / или безопасности учетной записи системы хост-компьютера.

Если вам нужна более надежная защита в случае физической потери, вы должны использовать SQL 2008 и полагаться на инфраструктуру EKM ( Extensible Key Management ), создайте мастер-ключ, хранящийся на физическом устройстве. Это повысит безопасность в случае компрометации носителей, поскольку для атаки необходим физический доступ к аппаратному крипто-модулю, в котором хранится главный ключ.

Процесс, который не нуждается в доступе к секретам, не нуждается ни в одном из них. В этом случае доступ осуществляется с помощью паролей, предоставляемых клиентскими приложениями, и эти пароли обычно получают от самого пользователя.

Если ваша система относится к первому типу (нуждается в автоматическом доступе к секретам и не запрашивает у текущего пользователя пароль доступа к секретам), тогда можно использовать иерархию шифрования (главный ключ базы данных, Сервисный мастер-ключ). Если приложение относится к более позднему типу (оно запрашивает у пользователя пароль для доступа к его собственным секретам), тогда правильное решение заключается в том, чтобы мастер-ассиметричный ключ был зашифрован с помощью пароля, предоставленного пользователем.

Нигде, и я должен подчеркнуть и повторить, NOWHERE в этих схемах есть место для секрета, сохраненного в файле, или мастер-пароля, сохраненного в таблице. Это просто главный дизайн # FAIL.

1 голос
/ 13 января 2010

хешируйте пароль и сохраняйте хеш. если пользователь забудет пароль, отправьте ему новый. также дайте ему возможность изменить его.

также подумайте о реализации регистрации openId, чтобы вам не пришлось беспокоиться о входах в систему.

0 голосов
/ 13 января 2010

Filesystem. Файл конфигурации, например, в каталоге, который может читать и / или записывать только учетная запись, под которой работает ваше приложение. Это предполагает, что вы, конечно, доверяете своим сотрудникам центра обработки данных.

С другой стороны, возможно, я не совсем правильно понял ваш вопрос. Если вы просто хотите хранить пароли пользователей в таблице, вы должны их хешировать (использовать соль), в идеале используя SHA-1. Никогда не храните пароли в виде открытого текста, независимо от того, какие разрешения БД вы используете.

...