Храните клиентский SSL-сертификат без ущерба для безопасности. - PullRequest
1 голос
/ 16 июля 2010

Я сохранил клиентский SSL-сертификат в базе данных в виде файла, а пароль его закрытого ключа - в столбце (не использующем хранилище сертификатов) для каждой веб-службы, для которой требуется сертификат. Причина, по которой я предпочел это, - мне не о чем беспокоитьсяпривилегия пользователя на доступ к сертификату, если код перемещен на другой сервер (Dev / QA / Prod).Поскольку сертификат хранится в централизованном месте, мне не нужно устанавливать его на каждом компьютере.Более того, деловые люди могут загружать сертификат в любое время без вмешательства разработчика, и сертификат будет отличаться для QA и производственной среды.Теперь я обеспокоен тем, что хранение сертификата в базе данных ставит под угрозу безопасность, а не хранит его в хранилище сертификатов?

Ответы [ 2 ]

1 голос
/ 17 июля 2010

С точки зрения безопасности ваша стратегия размещения закрытых ключей И пароля в базе данных отдает права на все ключи администратору базы данных, автору программного обеспечения И системному администратору.

Размещение пароля закрытого ключа в системе, но не в базе данных, дает полный контроль над системным администратором и автором программного обеспечения.

Еще одно решение - хранить закрытый ключ на аппаратном устройстве (HSM) и хранить только ссылки в вашей базе данных. В этом случае ваше программное обеспечение будет использовать аппаратный криптографический API, такой как PKCS # 11, для выполнения криптографического рукопожатия клиента SSL, и ваши личные ключи никогда не будут находиться в системной памяти или на диске вообще.

0 голосов
/ 17 июля 2010

Полагаю, вы имеете в виду «Я сохранил клиентский SSL-сертификат в базе данных в виде файла, его закрытый ключ и его пароль приватного ключа». Возможно, сертификат X.509 и его закрытый ключ находятся в одном контейнере, предположительно в формате PKCS # 12. (Или вы действительно хотите хранить только сертификат? Хранить только сертификат - это хорошо, но зачем вам хранить пароль закрытого ключа?)

Это не обязательно неправильно, но вы должны убедиться, что доступ к этой базе данных надежно защищен.

В общем, закрытый ключ действительно таков: личный . Некоторые сертификационные органы даже предписывают в своих политиках, чтобы никто, кроме конечного пользователя, не знал закрытый ключ (по крайней мере, с разумной защитой, например, в браузере или в файле PKCS # 12, для которого только они знают пароль). Это имеет смысл при использовании открытых и закрытых ключей.

Я думаю, вам нужно внимательно посмотреть на все углы вашего дизайна. Непонятно, почему вы хотите хранить закрытые ключи в базе данных для извлечения пользователями. Может иметь смысл хранить закрытые ключи в центральном месте, но это также может лишить смысла использование сертификата клиента для аутентификации (это действительно зависит от полной картины и степени безопасности, которую вы действительно хотите).

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...