Как защитить SSL-сертификат (Apache / CentOS)

В настоящее время я использую SSL-сертификат сервера без парольной фразы, чтобы Apache мог запускаться без присмотра.

Есть признаки от клиентов, требующие от нас более надежной защиты SSL-сертификата. Я еще не уверен, к чему они стремятся, но пока полагаю, что им не нужен незащищенный сертификат SSL на диске. Полагаю, я не могу избежать того, чтобы он оставался открытым в памяти Apache, но давайте предположим, что это приемлемо.

Я разработал продуманную систему, позволяющую хранить парольную фразу в памяти процесса на внутреннем сервере (т.е.не на переднем веб-сервере) и передавать ее переднему серверу с помощью Apache SSLPassPhraseDialog (http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslpassphrasedialog). При запуске внутреннего сервера необходимо будет ввести парольную фразу, и у нас будет несколько таких серверов с балансировкой нагрузки для обеспечения высокой доступности.

У меня вопрос:

Как «большие парни» защищают свой SSL-сертификат? Они просто заставляют свои устройства вводить парольную фразу при перезапуске сервера или хранят ее в незашифрованном виде, как и все мы?
Мой опыт работы с открытым исходным кодом показывает, что есть очень большая вероятность, что кто-то уже решил любую проблему, с которой я сталкиваюсь - такая система уже доступна?
Было бы разумно с точки зрения бизнеса просто сказать, что мы храним сертификат в незашифрованном виде и просто используем быстрые процедуры для его отзыва в случае кражи?

Я бы сказал, что «большие парни» осуществляют разгрузку SSL на кластерные балансировщики нагрузки переднего плана, поскольку это то, чем я занимаюсь, и я далеко не «большой мальчик».

я нашел эти инструкции на httpd.apache.org при удалении диалогового окна парольной фразы, которое вы, вероятно, видели, если искали проблему в Google, что, я полагаю, у вас есть.

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

Давайте сначала рассмотрим основы инфраструктуры открытого ключа в иерархической модели PKI.

Открытый ключ - это шифратор / шкафчик, встроенный в сертификат, созданный центром сертификации.
Закрытый ключ - это дешифратор / разблокировщик, используемый вместе с открытым ключом.
Открытые ключи и сертификаты не требуют конфиденциальности.
К закрытым ключам предъявляются требования конфиденциальности.

Следовательно, ваше беспокойство по поводу Apache должно быть связано с закрытым ключом, а не с открытым ключом. Типичный способ защиты секретного ключа инженером по безопасности - использование аппаратного модуля безопасности. Аппаратный модуль безопасности (HSM) может иметь множество форм-факторов, включая смарт-карту, карту PCIe, карту PCI, USB-ключ, USB-накопитель, сетевой HSM и другие. Соответственно, они могут покрыть большой объем бюджетов и возможностей безопасности.

Существуют некоторые HSM, которые имеют проверенные реализации безопасности, такие как FIPS 140-2 на уровнях 1 (обычно программное обеспечение), 2 физических (защита от несанкционированного доступа), 3 физических (защита от несанкционированного доступа и реакция на вторжение) и 4 физических (защита от несанкционированного доступа, реакция на вторжение и обнуление ключа) .

Чтобы оценить, следует ли вашему бизнесу что-то делать, я бы посмотрел на анализ рентабельности и оценку рисков, которые включают расчеты ALE, ARO и SLE. Однако, если вы ведете бизнес через Интернет, может быть лучше привлечь специалиста по веб-безопасности, чтобы он оценил всю вашу инфраструктуру и составил консолидированный список уязвимостей и слабых мест с приоритетным планом исправления, с которым вы можете работать. ваше руководство.