Чи є гарною практикою видалення пароля з ssl cert?

Зараз я читав у кількох блогах, що слід видаляти паролі із сертифікатів SSL, щоб уникнути підказок пароля під час перезавантаження Apache.

Це правда і чи несе це ризик для безпеки?

Так, це зупинить надсилання запитів до терміналу при запуску веб-сервера.

І так, це несе загрозу безпеці, оскільки там, де раніше було зашифровано сертифікат, він зараз є простим текстом. Це означає, що можливо викрасти повністю робочий сертифікат у машини.

Чи це несе для вас істотний ризик для безпеки, залежить від того, якими будуть наслідки, якби це сталося з вами і що ви отримуєте від цього таким чином.

Якщо для вас важливіше, що сервіси повинні перезавантажуватися граціозно, навіть якщо вони без нагляду, ніж безпека системи SSL в цілому, це відповідь прямого руху.

Особисто я вважаю, що зберігання дешифрованих копій сертифікатів SSL в цілому має більше плюсів, ніж мінусів для мого типового навантаження, ось чому;

1. Зловмисник все-таки матиме копію сертифіката, навіть якщо він був зашифрований, тому ваш обов'язок відкликати його все одно.
2. У наші дні зловмиснику набагато простіше отримати дійсний сертифікат для вашого сайту через соціальну інженерію, ніж викрасти робочу копію одного.
3. Сертифікати, природно, закінчуються, обмежуючи їхню атаку.
4. Хост-системи безпеки, такі як традиційно дозволи та SELinux, пропонують надійні засоби захисту сертифікатів на платформі.
5. Сертифікат - це не все-таки і не все захищена система. Існує багато інших аспектів, таких як дані, які ви зберігаєте, засоби масової інформації, на яких ви зберігаєте, а також значення та / або особистий характер даних.

Те, що може змусити мене шифрувати:

1. Якщо ви використовували сертифікат для здійснення взаємної автентифікації.
2. Це сертифікат підстановки або сертифікат, в якому розміщено декілька доменів (збитки подвійні, потрійні чи багато, для чого можна використовувати багато хостів)
3. Сертифікат є багатоцільовим якось іншим чином.
4. Метою сертифікатів є забезпечення цілісності даних про високу цінність (медичні записи, фінансові операції тощо).
5. Інший кінець очікує високого рівня довіри та / або залежить від цілісності вашої системи для прийняття оперативних рішень.

Зрештою, не покладайтеся на те, щоб інші приймали рішення щодо безпеки. Вам потрібно зважити ризики та визначити, що найкраще для вас та вашого закладу, використовуючи якомога більше інформації.

Це забезпечує трохи більше безпеки, але реальність полягає в тому, що якщо хтось потрапив достатньо далеко у вашу систему, щоб отримати доступ до вашого приватного ключа SSL, ніж у вас, мабуть, виникають більші проблеми.

З практичної точки зору, чи дійсно ви хочете бути там щоразу, коли апач потрібно перезапустити, щоб ввести пароль?

Одне, що ви можете зробити, це зберегти незахищене слово ключа на вашому сервері (та захистити його за допомогою звичайної системної безпеки) та зберегти резервну копію ключа, який ви зберігаєте в іншому місці паролем. Тож якщо хтось зможе виправити ключ з іншого місця, ніж з вашого сервера (набагато більше шансів, подумайте, що хтось ноутбук викрадений разом із ним на робочому столі) він все одно захищений.

Цифрові ключі, які використовуються для входу, повинні бути захищені паролем.

Якщо ви хочете, щоб служби на основі SSL перезапускалися без ручного втручання, у вас є два варіанти:

1. Не майте пароль на ключі та захищайте його, щоб доступ до нього мали лише сервіси, які потребують його.
2. Збережіть пароль у простому тексті або в рівному текстовому еквіваленті на сервері, щоб служби, які його потребували, могли надавати пароль. (Ви можете отримати кілька копій пароля в погано захищених файлах конфігурації.)

Резервні копії ключа повинні бути захищені паролем і захищені так, ніби вони не захищені паролем.