Настройка ELB с SSL - Что такое бэкэнд-аутентификация?

12

Я начал настройку Amazon Elastic Load Balancing Service для моего пула серверов, и мне нужно настроить HTTPS / SSL. У меня есть все мои настройки SSL-сертификатов, но затем я перехожу к шагу для бэкэнд-аутентификации, и я не уверен, какой сертификат требуется для «Бэкэнд-аутентификации».

Это закрытый ключ моего сайта, открытый ключ или мне нужно создать новый ключ на сервере?

Спасибо за помощь.

— whobutsb
источник

«Затем я перехожу к шагу для бэкэнд-аутентификации и не уверен, какой сертификат требуется для« Бэкэнд-аутентификации ». Это закрытый ключ моего сайта, открытый ключ или мне нужно сгенерировать новый ключ на сервере?» <---- У кого-нибудь есть ответ на эту часть вопроса? Это еще один сертификат SSL или файл .pm ключевой пары, который они дают вам при создании группы безопасности?

— Охотник Личмен

13

Предыдущий ответ не на 100% точен.

Что делает РЕАЛЬНАЯ Аутентификация, так это то, что открытый ключ вашего сервера отчетов (когда ELB общается с вашим сервером по протоколу HTTPS / SSL) соответствует открытому вами ключу. Это может помешать кому-либо подключить вредоносный сервер к вашему ELB или снизить вероятность перехвата трафика между ELB и вашими серверами.

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

В итоге

Пока ваш ELB связывается с вашим внутренним экземпляром через HTTPS, этот трафик зашифрован, хотя он может быть перехвачен. Внутренняя аутентификация помогает предотвратить перехват этого трафика.

Почему бы вам не использовать внутреннюю аутентификацию?

Производительность. С включенной внутренней аутентификацией мы видели увеличение времени отклика примерно на 50-70 мс при обмене данными через ELB (со всеми другими включенными HTTPS).

— Уильям Кинг
источник

1

Привет Уильям, спасибо за объяснение. Но какой вердикт, делать это или нет? Каковы шансы, что общение между эльбом и инстансами будет скомпрометировано? Или даже вредоносный сервер привязывается к эльбу?

— xor

Чтобы иметь возможность подключить вредоносный сервер к ELB, потребуются учетные данные AWS с правами регистрации ELB. Я бы сказал, что эти учетные данные хранятся на ваших серверах развертывания или у вас. Если эти учетные данные будут пропущены, существует также высокая вероятность того, что злоумышленник в любом случае сможет подключиться к вашему бэкэнду (поскольку вашим компьютерам развертывания необходимо обновить версии приложений, они, скорее всего, имеют какой-то доступ по SSH), поэтому шифрование бэкенда https, вероятно, не будет Разница в том, что злоумышленник может напрямую подключиться к бэкэндам.

— Кирилл Дюшон-Дорис

Если предположим, что я использую политику безопасности AWS по умолчанию - ELBSecurityPolicy-2016-18. Итак, какой открытый ключ или закрытый ключ будет использоваться для внутренней аутентификации.

— Шанкар

4

Внутренняя проверка подлинности гарантирует, что весь трафик к экземплярам, распределителю нагрузки и клиенту будет зашифрован.

У меня были некоторые проблемы с этой настройкой, но после некоторых копаний я нашел соответствующий раздел в Руководстве разработчика по упругой балансировке нагрузки , см. Создание балансировщика нагрузки с настройками шифра SSL и Аутентификация на внутреннем сервере - в частности, вы можете захотеть Прочтите, как этого добиться, используя Консоль управления AWS , которая предоставляет полезное пошаговое руководство и иллюстрации к различным темам.

— аф-на-работе
источник

Спасибо за ответ, извините, я не вернулась к вам раньше. Читая об этом сейчас!

— whobutsb