Как управлять защитой секретного ключа SSL веб-серверов (пароль против пароля)?

18

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

Веб-серверу необходим доступ к закрытому ключу для операции шифрования. Этот файл должен быть защищен от несанкционированного доступа. В то же время сервер должен запускаться автоматически, без вмешательства человека (если он достаточно безопасен).

Мы обсуждаем три варианта:

  1. Защитите ключ с помощью файловой системы.

  2. Используйте ключ, защищенный паролем, и вводите ключ вручную при каждом перезапуске.

  3. Используйте ключ, защищенный паролем, и сохраните ключ в файловой системе для автоматизации перезапуска.

Наши проблемы следующие:

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

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

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

Как вы управляете безопасностью закрытых ключей ваших серверов? Есть ли другие (более безопасные) варианты?

chmeee
источник

Ответы:

10

Вариант 1 - это я считаю принятым стандартом.

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

Таким образом, пароль хранится на компьютере, но не на том же, на котором работает apache, а не в вашей DMZ. Вы получаете дополнительную безопасность при использовании ключевой фразы и сохраняете возможность автоматического перезапуска.

казарка
источник
5

Если кто-то имеет достаточный доступ к серверу для чтения ключа, то он, скорее всего, также имеет достаточный доступ для подключения отладчика и получения ключа из памяти.

Если вам не нравится просыпаться среди ночи, чтобы вводить пароли, переходите к варианту 1. Если у вас много серверов, вы хотите автоматически перезапускаться при сбое, а вариант 2 этого не позволяет.

Брайен-бразилия
источник
1

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

Как вы поняли, вариант 3. не обеспечивает дополнительной защиты сверх 1.

Дэвид Шмитт
источник
1

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

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

Как вы упомянули, опция (3) с точки зрения безопасности аналогична опции (1).

Neobyte
источник