Як зберігати ключ конфіденційності для нашого веб-сайту?

Я хочу зберегти конфіденційність нашого ключа SSL для нашого веб-сайту. Він зберігається на 2 USB-накопичувачах, один у сейфі та один, який я зберігаю в безпеці. І тоді я єдиний, хто застосовує це до веб-сервера, щоб він був повністю захищеним.

За винятком ...

Принаймні, на IIS ви можете експортувати ключ. Тож кожен, хто є адміністратором, може отримати копію ключа. Чи є спосіб обходити це? Або за визначенням усі адміністратори мають повний доступ до всіх клавіш?

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

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

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

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

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

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

Коли ви імпортуєте ключ, у вас є можливість позначити його як неекспортний. Це не дозволить вам використовувати IIS або сертифікат MMC для його експорту. Принаймні, це робить трохи складніше.

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

У цьому може допомогти «проміжний СА».

У цьому прикладі "Root CA" належить компанії SSL, а не ви.

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

Але:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key for site

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

Ви зберігаєте приватний ключ CA середнього, і адміністраторам не потрібно його бачити.

Ви також можете зробити це:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key 1 for site
   +-Server Key 2 for site 
   +-Server Key 3 for site

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

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

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

Детальніше читайте на: https://www.thesslstore.com/blog/heres-what-happens-when-your-private-key-gets-compromised/

На відміну від цього, SSL-сертифікати призначені для веб-сайтів, щоб забезпечити HTTPS-зв’язок: приватний ключ потрібен під час кожного рукостискання веб-сервером. Тому зберігати його в режимі офлайн не вийде.