Используя Elastic Load Balancer, достаточно легко настроить SSL на внешнем балансировщике нагрузки и обслуживать запросы как http к приложению.
При запуске одного сервера также можно настроить SSL на веб-сервере (Tomcat) или в приложении (Spring).
При работе с балансировщиком нагрузки нужно ли подтягивать SSL до уровня балансировщика нагрузки? Есть ли в SSL-соединении элемент состояния, который будет потерян при пересылке все еще зашифрованного трафика?
Боюсь, что ответ будет «смотря по обстоятельствам». Мне приходилось немного вникать, когда я работал с безопасностью интернет-банкинга. Однако это было пару лет назад, поэтому вполне возможно, что кто-то другой придумает что-то, что я забыл или что изменилось за эти годы.
Во-первых, при этом можно потерять состояние - если у вас запущено приложение, которому для сохранения состояния требуются некоторые заголовки SSL. Если это так, вы, вероятно, потеряете эту информацию (хотя вы можете настроить балансировщики нагрузки для ее пересылки каким-либо образом). Одним из примеров может быть использование клиентских сертификатов для аутентификации.
Во-вторых, как говорит Базз, это делает ваш трафик уязвимым для перехвата в локальной сети. Насколько это опасно, конечно, будет зависеть от того, как выглядит ваша сеть, а также от того, какой это трафик.
Вы уменьшаете нагрузку на свои веб-серверы, поскольку им больше не нужно тратить свои ресурсы на расшифровку и шифрование.
При изменении конфигурации веб-сервера вы можете выполнить простую перезагрузку apache, не вводя пароль ключа SSL. Это означает, что вы можете автоматизировать его, обеспечивая непрерывное развертывание, DevOps и другие модные слова. (Обратной стороной этого является то, что для изменения конфигурации LB может потребоваться ввести пароль, но, как правило, вы делаете это не так часто, как возитесь с конфигурацией apache ...)
Устранение неполадок веб-сервера и приложения стало намного проще, так как теперь вы можете отслеживать / tcpdump входящий трафик напрямую.
У вас меньше мест, где можно исправить ошибки / дыры в безопасности SSL. Обычно намного проще изменить настройки SSL на одном LB, чем на большом количестве веб-серверов, особенно если эти серверы управляются множеством разных людей из разных отделов.
Аудит SSL также намного проще, когда есть только одно место для аудита.
Намного легче отслеживать, какие сертификаты используются и когда их нужно обновить, когда все они собраны в одном месте. У вас больше нет проблемы с тем, что Боб заказал сертификат и поместил свой личный адрес электронной почты в систему для напоминаний, а затем ушел или был уволен, так что напоминание отскакивает и сертификат истекает, и внезапно у вас появляется много расстроенных людей, требующих этого это исправить прямо сейчас! (Не то чтобы такое случалось везде, где я работал! кашель)
Хорошая идея - завершить работу в LB или нет, будет зависеть от того, как вы цените различные преимущества и недостатки. Как правило, я бы сказал, что, если нет веской причины поступить иначе, вы захотите устранить сложность как можно раньше - на границе сети, если это разумно с точки зрения безопасности и удобства использования, или как можно скорее после этого. возможно.
Я бы сказал, что прерывание SSL-трафика на уровне балансировщика нагрузки или сервера зависит от того, согласны ли вы с незашифрованным трафиком, проходящим между ними или нет. В большинстве случаев трафик, идущий от балансировщика нагрузки к серверу (-ам), проходит внутри частной сети, где вам действительно не нужно заботиться о подслушивании и атаках типа `` человек посередине '' (по сравнению с трафиком, проходящим через общедоступный Интернет).
Предоставление терминации ELB также избавляет вас от лишней работы по терминации трафика самостоятельно.
Здесь вы можете прочитать об этом подробнее: https://security.stackexchange.com/a/30413
Пара дополнительных мыслей: 1. Если вы ищете соответствие PCI, вам нужно будет зашифровать «данные в пути», поэтому вам придется либо передавать зашифрованный трафик в ваше приложение, либо повторно шифровать между LB и вашим сервером приложений.