На границе системы TLS завершается на обратном прокси, а до приложения данные идут по обычной сети. Какой защитный эффект теряется?
Теряется защита участка между обратным прокси и приложением: данные там больше не обеспечены конфиденциальностью и целостностью TLS. Любой компонент, способный прослушивать или изменять этот трафик, может прочитать запросы и ответы либо вмешаться в них. TLS защищает только соединение между клиентом и точкой завершения, а не весь последующий маршрут.
TLS создавался как механизм защиты канала между двумя конечными сторонами: он шифрует передаваемые данные, проверяет подлинность сервера и обнаруживает изменение сообщений. По мере роста веб-систем появились обратные прокси, балансировщики и шлюзы, на которых удобно централизованно завершать TLS.
Такой подход упростил управление сертификатами и разгрузил приложения, но фактически переместил конечную точку защищённого канала. Участок после прокси перестал автоматически наследовать свойства внешнего TLS-соединения.
Клиент устанавливает защищённое соединение с прокси и проверяет сертификат прокси. Приложение за прокси не является участником этого TLS-сеанса, поэтому клиент не проверяет подлинность именно приложения.
Если внутренний сегмент считается полностью доверенным, это может долго оставаться незаметным. Однако компрометация соседнего сервиса, доступ к сетевому зеркалированию трафика, ошибочная маршрутизация или недобросовестный администратор создают возможность раскрытия токенов, персональных данных и содержимого запросов.
Изменение трафика также опасно: злоумышленник может попытаться подменить параметры запроса или ответ, если приложение не использует дополнительную защиту на этом участке. Внутреннее расположение узла само по себе не является криптографической гарантией доверия.
Если требуется защитить весь путь, прокси должен установить отдельное TLS-соединение с приложением. Это называется повторным шифрованием или TLS re-encryption: прокси расшифровывает внешний запрос для обработки, затем отправляет его приложению по новому защищённому каналу.
Для усиления аутентификации между прокси и приложением применяют взаимную TLS-аутентификацию (mTLS). В этом случае приложение проверяет сертификат прокси, а прокси может проверять сертификат приложения. Одного шифрования без проверки стороны недостаточно: иначе можно подключиться к подменённому узлу, если доверие к сертификату настроено неправильно.
Сертификаты внутренних сервисов нужно выпускать через управляемый центр сертификации, регулярно обновлять и отзывать при компрометации. Важно также ограничить сетевую доступность приложения: шифрование не заменяет сегментацию и правила межсервисного доступа.
У повторного TLS есть цена: усложняется управление сертификатами, появляется дополнительная нагрузка на установление соединений и необходимость корректно передавать сведения о первоначальном клиенте. Заголовки вроде информации о клиентском IP нельзя считать достоверными без контроля со стороны доверенного прокси; приложение должно принимать их только от разрешённых источников.
Если прокси и приложение находятся на одном защищённом узле, риск может быть приемлемым, но это нужно обосновать моделью угроз. Если же между ними есть отдельные виртуальные машины, хосты, зоны или сетевое оборудование, открытый трафик следует считать потенциально доступным другим участникам среды.
Платёжный API принимал HTTPS на балансировщике, после чего балансировщик отправлял запросы к нескольким экземплярам приложения по HTTP. Внутренняя сеть была изолирована от Интернета, поэтому первоначально повторное шифрование сочли избыточным.
Рассматривались два варианта. Первый — оставить HTTP и полагаться на изоляцию сети: это проще, дешевле и не требует внутренней PKI, но не защищает от компрометации узла в том же сегменте. Второй — использовать TLS между балансировщиком и приложениями с проверкой сертификатов: это повышает защищённость, но требует автоматической выдачи, ротации и контроля доверенных сертификатов.
Выбрали второй вариант с mTLS, потому что запросы содержали платёжные данные, а модель угроз включала компрометацию соседнего сервиса. После внедрения доступ к приложениям разрешили только с сертификатами балансировщиков, а HTTP-порты закрыли сетевыми правилами. В результате даже перехват внутреннего трафика не давал содержимого запросов, а неавторизованный узел не мог выступить доверенным отправителем.
Нет. Шифрование скрывает данные от наблюдателя, но без аутентификации получателя прокси может установить защищённое соединение с подменённым или ошибочно настроенным узлом. Нужно проверять имя или идентификатор приложения в сертификате и доверять только нужному центру сертификации; для строгой двусторонней проверки используют mTLS.
Нет. Прокси завершает внешний TLS, поэтому видит открытое содержимое запроса и ответа. Внутренний TLS защищает участок после прокси от сетевых наблюдателей, но не от компрометации или злоупотребления самим прокси. Если прокси нельзя полностью доверять, нужны сквозное шифрование на уровне сообщения, минимизация данных и отдельная проверка авторизации приложением.
Если клиентский сертификат предъявляется внешнему TLS-сеансу, его напрямую видит прокси, а приложение получает только переданные прокси сведения. Эти сведения нельзя безоговорочно считать доказательством личности клиента: скомпрометированный прокси может их подделать. Для сохранения доверия приложение должно аутентифицировать прокси, контролировать канал между ними и применять протокол передачи проверенных атрибутов с защитой от подмены; в некоторых архитектурах клиентскую проверку выполняют непосредственно на сервисе.