Де компанії зазвичай зберігають сертифікати SSL для подальшого використання?

Нещодавно ми придбали сертифікат 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

Ще одним варіантом, прочитавши про KeyWhiz, був Сейф HashiCorp. Це не просто менеджер паролів, а магазин Secrets, я вважаю дещо схожим на KeyWhiz. Її написано в GO, і клієнт працює як сервер, і з'єднується з купою резервних копій та методами аутентифікації. Сейф також є відкритим кодом, з опцією Enterprise.

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

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

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

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