Недавно мы купили шаблон SSL-сертификата для нашего домена. Мы преобразовали все сертификаты в хранилище ключей Java, но теперь задаемся вопросом, где их хранить для дальнейшего использования.
Люди используют систему управления версиями, такую как BitBucket, для этих типов файлов или просто генерируют каждый раз, когда это необходимо, или что-то еще?
Нам интересно, есть ли стандартное решение или какие-либо «лучшие практики» по хранению этих сертификатов для использования в будущем.
Есть несколько решений:
Один путь - это конкретное хранилище ключей либо аппаратное устройство, либо аппаратный модуль безопасности или эквивалент на основе программного обеспечения.
Другой - просто отозвать старый ключ и сгенерировать новую пару закрытого / открытого ключей, когда возникнет ситуация. Это несколько смещает проблему с поддержания безопасности ключа на защиту имени пользователя / пароля учетной записи у поставщика сертификатов и их процедур для повторной выдачи. Преимущество заключается в том, что у большинства организаций уже есть решение для управления привилегированными учетными записями, например 1 2
Существует несколько способов автономного хранения: от распечатки печатной копии закрытой и открытой пары ключей, включая пароль (но это будет собака для восстановления), до простого хранения их на цифровых носителях, рассчитанных на длительное хранение. .
На самом деле плохие места - это GitHub, WiKi вашей команды или сетевой ресурс (и вы поняли).
Обновление 2015/4/29: Keywhiz тоже кажется интересным подходом.
Нет, сертификаты SSL не входят в систему управления версиями, по крайней мере, не в часть закрытого ключа.
Относитесь к ним, как к паролю. Наши фактически хранятся точно так же, как и наши пароли - в KeePass. Он позволяет прикреплять файлы и зашифрован.
Если вы поместите закрытый ключ в систему контроля версий, любой, кто имеет к нему доступ, сможет выдавать себя за ваш сервер. Если ваш веб-сервер не использует 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
Я бы рекомендовал изучить автономный HSM (например, токен аппаратного шифрования или CAC) для хранения закрытого ключа и сертификата. Это не только защищает закрытый ключ от случайного взлома, но и обеспечивает некоторую базовую криптографическую разгрузку.
Если у вас есть больше криптографических активов для управления, я бы порекомендовал изучить программное обеспечение для управления корпоративными ключами и сертификатами, которое может автоматизировать продление, отслеживать жизненный цикл, автоматизировать предоставление конечным точкам и т. Д. Большинство из них хранят активы в зашифрованном виде в состоянии покоя. CLOB в базе данных.
Еще одним вариантом, после прочтения о KeyWhiz, было хранилище HashiCorp. Это не просто менеджер паролей, а магазин секретов, который, как мне кажется, чем-то похож на KeyWhiz. Он написан на GO, а клиент также работает как сервер и подключается к множеству бэкэндов и методов аутентификации. Vault также имеет открытый исходный код с опцией Enterprise.
Поскольку ключи и сертификаты SSL - это просто текстовые файлы, вы можете кодировать их в base64 и сохранять в виде строки в Vault или даже просто текста в Vault. Нет WebUI или GUI, все его командной строки или сценария, и есть очень хороший, стабильный веб-API для загрузки.