Есть ли какая-либо угроза безопасности, если мы устанавливаем сертификат SSL в подсистеме балансировки нагрузки вместо серверов?

Это, вероятно, лучше при сбое сервера, но здесь я попробую.

Нет повышенного риска безопасности для самого сертификата SSL только потому, что вы поместили сертификат SSL на балансировщик нагрузки, если балансировщик нагрузки настроен правильно и не обслуживает закрытый ключ. Этот риск существует на любом сервере, будь то балансировщик нагрузки или нет, новая компрометация ОС или атака могут, хотя маловероятно, позволить этому произойти.

Однако в зависимости от того, как вы это делаете, трафик за балансировщиком нагрузки может быть отправлен в незашифрованном виде, если балансировщик нагрузки передает HTTP только на серверы содержимого. Таким образом, вам необходимо настроить перенаправленные соединения для использования HTTPS либо с использованием внутренних сертификатов и вашего собственного центра сертификации, либо путем установки внешнего сертификата HTTPS на контент-серверах (и вы Вам нужно будет это сделать, если вы стремитесь к соответствию PCI).

Помните, что существует также риск нагрузки, шифрование стоит дорого, и, помещая сертификат в балансировщик нагрузки, он увеличивает, errr, нагрузку на него. Если балансировщик нагрузки уже чрезмерно растянут, это может быть последней каплей. Если вы просматриваете множество транзакций, вы, как правило, видите аппаратное SSL-устройство, сидящее перед балансировщиком нагрузки, которое заботится о трафике SSL, а затем передает HTTP-соединение с балансировщиком нагрузки, который передает HTTP-соединение с серверами содержимого. (Опять же, это должен быть HTTPS, если вы стремитесь к соответствию PCI)

Если балансировщик нагрузки уже чрезмерно растянут, это может быть последней каплей. Если вы просматриваете множество транзакций, вы, как правило, видите аппаратное SSL-устройство, сидящее перед балансировщиком нагрузки, которое заботится о трафике SSL, а затем передает HTTP-соединение с балансировщиком нагрузки, который передает HTTP-соединение с серверами содержимого. (Опять же, это должен быть HTTPS, если вы стремитесь к соответствию PCI)

Если балансировщик нагрузки уже чрезмерно растянут, это может стать последней каплей. Если вы просматриваете множество транзакций, вы, как правило, видите аппаратное SSL-устройство, сидящее перед балансировщиком нагрузки, которое заботится о трафике SSL, а затем передает HTTP-соединение с балансировщиком нагрузки, который передает HTTP-соединение с серверами содержимого. (Опять же, это должен быть HTTPS, если вы стремитесь к соответствию PCI)

There are many levels of load balancing. You don't have choice but to put cert in the load balancer in most popular configurations.

For example, if you are proxying the HTTP traffic in the load balancer, it has to terminate the SSL connection so it must have the cert.

Normally, the load balancer lives in the secure zone so you don't have to use SSL between balancer and your server. If that's not the case, you can use SSL again but you defeat the purpose of the SSL acceleration feature on most switches.

Вот последствия, о которых я мог подумать:

• Если вы повторно не зашифруете трафик между ускорителем SSL и конечным сервером, трафик во внутренней сети будет в виде открытого текста. Это может привести к тому, что другая уязвимость безопасности станет более опасной. В зависимости от ваших юридических и договорных требований в отношении передаваемых данных, это может быть неприемлемым.
• Вы потеряете возможность использовать сертификат X509 для идентификации клиентов. Это может быть проблемой или нет, в зависимости от того, что вы делаете.

Что касается управления сертификатами, вы храните закрытый ключ на ускорителе SSL, а не на сервере. На самом деле это может быть преимуществом, потому что, если веб-сервер будет скомпрометирован,