В группе безопасности моей компании мы обсуждаем худшие из следующих вариантов управления закрытым ключом SSL.
Веб-серверу необходим доступ к закрытому ключу для операции шифрования. Этот файл должен быть защищен от несанкционированного доступа. При этом сервер должен запускаться автоматически, без вмешательства человека (если он достаточно безопасен).
Мы обсуждаем три варианта:
Защитите ключ с помощью файловой системы perms.
Используйте ключ, защищенный паролем, и вводите ключ вручную при каждом перезапуске.
Используйте ключ, защищенный паролем, и сохраните ключ в файловой системе, чтобы автоматизировать перезапуск.
Наши опасения заключаются в следующем:
При выборе варианта 1 перезапуски выполняются автоматически, но при компромиссе можно скопировать закрытый ключ и, поскольку он не защищен, можно будет расшифровать обмен данными или выдать себя за наши серверы.
Вариант 2 кажется более безопасным, но он требует вмешательства человека, и системные администраторы обеспокоены, если это произойдет в нерабочее время. Кроме того, пароль должен быть передан нескольким системным администраторам, и вы знаете, что общий секрет больше не является секретом.
Вариант 3 имеет лучшее из обоих предыдущих вариантов, но если у кого-то есть доступ к ключу, он также может иметь доступ к паролю :(, поэтому он вообще не кажется таким безопасным.
Как вы обеспечиваете безопасность закрытых ключей своих серверов? Есть ли другие (более безопасные) варианты?
Вариант 1 - я считаю принятым стандартом.
Однако, если вам действительно нужна дополнительная безопасность, почему бы вам не настроить безопасный сервер (не в вашей DMZ) для мониторинга вашего веб-сервера, и если apache выйдет из строя, он может автоматически войти в систему удаленно и перезапустить apache, указав кодовую фразу.
Таким образом, кодовая фраза хранится на компьютере, но не на том же, на котором работает apache, и не в вашей DMZ. Вы получаете дополнительную безопасность, используя парольную фразу, и сохраняете возможность автоматического перезапуска.
Если у кого-то есть достаточный доступ к серверу для чтения ключа, то он, скорее всего, также имеет достаточно доступа, чтобы подключить отладчик и получить ключ из памяти.
Если вам не нравится просыпаться посреди ночи для ввода паролей, выберите вариант 1. Если у вас много серверов, вы хотите автоматически перезапускать сервер в случае сбоя, а вариант 2 не позволяет этого.
Одна из возможностей повышения безопасности, чем 1., но меньшего времени простоя, чем 2. - это создание закрытых ключей с коротким сроком действия и их регулярная переработка. Таким образом, вы можете хранить их без парольной фразы, но уменьшить окно уязвимости.
Как вы заметили, вариант 3. не обеспечивает дополнительной безопасности по сравнению с 1.
Практика подсказывает, что почти во всех ситуациях вы в конечном итоге будете использовать вариант (1). Perms файловой системы - лучший способ пойти в большинстве сценариев безопасности и практических.
В системе * nix вы можете ограничить закрытый ключ только root, так как большинство хороших веб-серверов (например, apache) будут запускаться как root, но понизят свои привилегии до ограниченного пользователя, как только у них появятся необходимые им привилегированные порты (80, 443 и т. Д.) .
Как вы упомянули, вариант (3) с точки зрения безопасности такой же, как вариант (1).