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


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

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

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


23
2017-12-01 21:40


Источник


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


Ответы:


Существует несколько решений:

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

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

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

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

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


20
2017-12-01 22:27



Мне любопытно, что вы подразумеваете под «программным эквивалентом» для HSM?
Некоторые производители оборудования теперь продают свою технику также в виде виртуального устройства, виртуальной машины. Есть также такие вещи, как Ключевое хранилище Oracle и открытый источник SoftHSM чтобы назвать некоторые. - HBruijn♦
Таким образом, в основном это позволяет превратить стандартный компьютер в HSM ...
«но это будет женская собака для восстановления» -> Этот день сделал мой день! Шутки в сторону, вы должны зашифровать его перед сохранением. - Ismael Miguel
По определению вы будете публиковать свой открытый ключ всем. Нет причин для шифрования этого. Но это не причина быть неаккуратным с этим. Безопасность - это, прежде всего, секретный ключ, который обычно должен быть зашифрован / защищен паролем. Вы должны стремиться иметь как можно меньше копий. - HBruijn♦


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

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


19
2017-12-01 21:58





Если вы поместите закрытый ключ в исходный элемент управления, любой, у кого есть доступ к нему, сможет выдавать себя за ваш сервер. Если ваш веб-сервер не использует 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

3
2017-12-02 02:09



Если ты делать что-то правильно то даже разоблачение секретного ключа не должно приводить к компрометации прошлого трафика, хотя это, безусловно, бы сделать MITM'ing для того, чтобы значительно облегчить будущий трафик. - Michael Kjörling
Привет @Michael, теоретически, но, к сожалению, мне удалось расшифровать множество захватов Apache и IIS, поэтому я могу только предположить, что PFS отключена по умолчанию. Даже многие IPSEC VPN отключены. - Tricky
По умолчанию PFS не так уж и выключен, поскольку он не поддерживается многими наборами шифров. Попробуйте протестировать сервер SSL Labs некоторое время; он указывает, какие шифровые наборы поддерживают FS. Разумеется, отключение всех наборов шифров не-FS может привести к тому, что многие клиенты останутся на холоде, потому что они не поддерживают комплекты шифрования FS. Однако предоставление привилегий для FS-пакетов должно работать, но я настоятельно рекомендую вручную заказать комплекты шифров, если вы не знаете, что делаете, и их относительные сильные и слабые стороны). - Michael Kjörling
Спасибо за рекомендацию по SSL Labs @Michael. К сожалению, мои серверы не сталкиваются с доступом в Интернет, но у меня была игра с включенными шифрами, и, как вы полагаете, PFS, похоже, поддерживается только некоторыми шифрами. PFS действительно мешает мне декодировать трассировки пакетов. Я соответствующим образом обновлю ответ. - Tricky


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

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


0
2017-12-02 02:33



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


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

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

  1. https://www.vaultproject.io/
  2. https://github.com/hashicorp/vault

0
2017-08-18 23:35