Як керувати захистом приватного ключа SSL веб-серверів (пароль проти пароля)?

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

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

Ми обговорюємо три варіанти:

1. Захистіть ключ за допомогою файлової системи.

2. Використовуйте захищений паролем ключ і введіть його вручну при кожному перезапуску.

3. Використовуйте захищений паролем ключ і зберігайте ключ у файловій системі для автоматизованого перезавантаження.

Наші проблеми:

1. З варіантом 1 перезавантаження автоматичні, але компроміс може скопіювати приватний ключ, і, як це не захищено, може використовуватися для децифірування зв'язку або видання себе за сервер.

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

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

Як ви керуєте безпекою приватних ключів ваших серверів? Чи є інші (більш безпечні) варіанти?

Варіант 1 - я вважаю прийнятим стандартом.

Однак якщо ви справді хочете отримати додатковий захист, чому б у вас не був встановлений захищений сервер (не у вашому DMZ), щоб контролювати ваш веб-сервер, і якщо apache знизиться, він може автоматично входити в систему і віддалено запускати apache , постачаючи фразу.

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

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

Якщо ви дійсно не любите прокидатися посеред ночі, набираючи паролі, перейдіть на варіант 1. Коли у вас є багато серверів, ви хочете автоматично перезапустити при відмові, а варіант 2 не дозволяє цього.

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

Як ви визнали, варіант 3. не забезпечує додаткового захисту понад 1.

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

У системі * nix ви можете обмежити приватний ключ тільки для root, оскільки більшість хороших веб-серверів (наприклад, апаш) запускаються як root, але знижують свої приватні файли до обмеженого користувача, як тільки вони матимуть необхідні їм привілейовані порти (80, 443 тощо) .

Як ви згадали, варіант (3) з точки зору безпеки такий же, як варіант (1).