Где компании обычно хранят сертификаты SSL для будущего использования?

26

Недавно мы приобрели сертификат SSL для нашего домена. Мы преобразовали все сертификаты в хранилище ключей Java, но теперь мы спрашиваем себя, где мы должны хранить их для дальнейшего использования.

Используют ли люди управление исходным кодом, например, BitBucket, для этих типов файлов или просто генерируют каждый раз, когда это необходимо, или что-то еще?

Нам интересно, есть ли стандартное решение или какие-либо "лучшие практики" для хранения этих сертификатов для будущего использования.

ssl-certificate certificate best-practices

— AmericanKryptonite
источник

Резервное копирование их в зашифрованном виде в ваше традиционное решение для резервного копирования. Не храните закрытые ключи в незашифрованном виде у любого внешнего провайдера. Я обычно включаю дату выпуска и срок годности в свой сертификат и имя файла ключа для разграничения.

— Андрей Домашек,

22

Есть несколько решений:

Один из вариантов - это конкретное хранилище ключей либо на основе аппаратного устройства, либо модуля аппаратного обеспечения безопасности, либо аналога на основе программного обеспечения.

Другой способ - просто отозвать старый ключ и сгенерировать новую пару секретный / открытый ключ при возникновении ситуации. Это несколько сдвигает проблему от поддержания безопасности ключа к защите имени пользователя / пароля учетной записи с поставщиком сертификатов и их процедур для повторной выдачи. Преимущество заключается в том, что большинство организаций уже имеют привилегированное решение для управления учетными записями, например 1 2

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

Действительно плохие места - это GitHub, ваша команда WiKi или сетевой ресурс (и вы поняли).

Обновление 2015/4/29: Keywhiz кажется интересным подходом.

— HBruijn
источник

Мне интересно, что вы подразумеваете под "программным эквивалентом" для HSM?

Некоторые из поставщиков аппаратных устройств в настоящее время продают свои устройства также в виде виртуальных устройств, ВМ. Есть также такие вещи, как хранилище ключей Oracle и SoftHSM с открытым исходным кодом .

— HBruijn

Так что, в основном, это позволяет превратить стандартный компьютер в HSM ...

1

"но это будет сука для восстановления" -> Этот сделал мой день! Помимо шуток, вы должны зашифровать его перед сохранением.

— Исмаэль Мигель

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

— HBruijn

21

Нет, сертификаты SSL не входят в систему контроля версий, по крайней мере, в часть закрытого ключа.

Обращайтесь с ними так же, как с паролем. Наши фактически хранятся точно так же, как и наши пароли - в KeePass. Он позволяет прикреплять файлы и шифруется.

— Грант
источник

3

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

Вы можете защитить ключ с помощью DES или AES, зашифровав его парольной фразой с использованием OpenSSL. OpenSSL доступен для Linux, OSX и Windows.

OpenSSL также может удалить фразу-пароль, если она не удобна (например, на веб-сервере, который запускается автоматически, но не поддерживает автоматический ввод фраз-паролей).

Добавление ключевой фразы с использованием шифрования AES (более безопасно, чем DES): -

openssl rsa -aes256 -in private.key -out encrypted.private.key

Удаление фразы-пароля (вам будет предложено ввести фразу-пароль): -

openssl rsa -in encrypted.private.key -out decrypted.private.key

— запутанный
источник

1

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

— CVN

Привет @ Майкл, Теоретически, но, к сожалению, я смог расшифровать многие записи Apache и IIS, так что я могу только предполагать, что PFS по умолчанию отключен. Даже у многих IPSEC VPN он отключен.

— Хитрый

По умолчанию PFS не так сильно отключен, поскольку не поддерживается многими комплектами шифров. Попробуйте тестирование сервера SSL Labs некоторое время; это указывает, какие наборы шифров поддерживают FS. Конечно, отключение всех наборов шифров, отличных от FS, может привести к тому, что многие клиенты не будут работать, поскольку они не поддерживают наборы шифров FS. Однако предоставление комплектов FS предпочтительным образом должно работать (но я настоятельно рекомендую не заказывать комплекты шифров вручную, если вы не знаете, что делаете, а также относительно их сильных и слабых сторон).

— CVN

Спасибо за рекомендацию по SSL Labs @Michael. К сожалению, мои серверы не подключены к Интернету, но я поэкспериментировал с включенными шифрами, и, как вы предполагаете, PFS поддерживается только некоторыми шифрами. PFS действительно мешает мне декодировать следы пакетов. Я обновлю свой ответ соответственно.

— Хитрый

1

Другой вариант, после прочтения о KeyWhiz, был Хранилище HashiCorp. Это не просто менеджер паролей, а хранилище секретов, я думаю, что-то похожее на KeyWhiz. Он написан на GO, и клиент также работает как сервер, и подключается к множеству бэкэндов и методов аутентификации. Vault также с открытым исходным кодом, с опцией Enterprise также.

Поскольку ключи SSL и сертификаты являются просто текстовыми файлами, вы можете кодировать их с помощью base64 и сохранять их в виде строки в Vault или даже просто в виде текста в Vault. Здесь нет WebUI или GUI, его командной строки или скриптов, и он имеет очень хороший, стабильный веб-API для загрузки.

— Pred
источник

0

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

Если у вас есть больше криптографических активов для управления, я бы порекомендовал обратиться к программному обеспечению Enterprise Key & Certificate Management, которое может автоматизировать обновления, отслеживать жизненный цикл, автоматизировать подготовку к конечным точкам и т. Д. Большинство из них хранит актив в зашифрованном виде в состоянии покоя. CLOB в базе данных.

— ДТК
источник

Почему отрицательные голоса? Не жалуюсь; Любопытно, что не так с этим ответом.

— Мэтт

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

— Хитрый