Поделиться через

Обзор завершения сеансов TLS и использования сквозного режима TLS в Шлюзе приложений

  • Статья

Протокол TLS, ранее известный как SSL, является стандартной технологией безопасности для установления зашифрованного соединения между веб-сервером и браузером. Эта связь гарантирует, что все данные, передаваемые между веб-сервером и браузерами, остаются закрытыми и зашифрованными. Шлюз приложений поддерживает как завершение сеансов TLS на шлюзе, так и сквозное шифрование TLS.

завершение сеанса TLS;

Шлюз приложений поддерживает завершение сеансов TLS на шлюзе, после чего трафик обычно передается в незашифрованном виде на внутренние серверы. Завершение сеансов TLS на шлюзе приложений дает ряд преимуществ.

  • Улучшенная производительность. Наибольшее влияние на производительность расшифровка TLS оказывает в момент первоначального подтверждения. Для повышения производительности сервер, выполняющий расшифровку, кэширует идентификаторы сеанса TLS и управляет его билетами. Если это выполняется в шлюзе приложений, все запросы от одного клиента могут использовать кэшированные значения. Если это делается на внутренних серверах, каждый раз, когда запросы клиента отправляются на другой сервер, клиент должен повторно пройти проверку подлинности. Использование запросов TLS может помочь устранить эту проблему, но они не поддерживаются всеми клиентами и могут быть трудно настроить и управлять ими.
  • Более эффективное использование внутренних серверов. Обработка SSL/TLS создает большую нагрузку на процессор, которая растет по мере увеличения размеров ключей. Устранение этого рабочего процесса с внутренних серверов позволяет использовать их более эффективно по прямому назначению: для доставки содержимого.
  • Интеллектуальная маршрутизация. Расшифровывая трафик, шлюз приложений получает доступ к содержимому запроса, в том числе заголовкам, URI и т. п., и может использовать эти данные для маршрутизации запросов.
  • Управление сертификатами. Нет необходимости приобретать и устанавливать сертификаты на все внутренние серверы. Достаточно сделать это для шлюза приложений. Это сэкономит время и деньги.

Чтобы настроить завершение TLS, необходимо добавить в прослушиватель сертификат TLS/SSL. Это позволяет Шлюз приложений расшифровать входящий трафик и зашифровать трафик ответа клиенту. Сертификат, предоставленный Шлюз приложений, должен находиться в формате PFX, который содержит как закрытые, так и открытые ключи. Поддерживаемые алгоритмы PFX перечислены в функции PFXImportCertStore.

Важно!

Для сертификата в прослушивателе нужно передать всю цепочку сертификатов (корневой сертификат из центра сертификации, все промежуточные и конечный сертификаты), чтобы создать цепочку доверия.

Примечание.

Шлюз приложений не предоставляет никаких возможностей для создания нового сертификата или отправки запроса на сертификат в центр сертификации.

Чтобы TLS-подключение работало, сертификат TLS/SSL должен соответствовать следующим условиям:

  • Текущие дата и время находятся в пределах диапазона "Действителен с" и "Действителен до" для сертификата.
  • Общее имя сертификата соответствует заголовку узла в запросе. Например, если клиент запрашивает https://www.contoso.com/, то должно использоваться общее имя www.contoso.com.

Если у вас есть ошибки с общим именем внутреннего сертификата (CN), ознакомьтесь с нашим руководством по устранению неполадок.

Поддерживаемые сертификаты для завершения сеансов TLS

Шлюз приложений поддерживает использование сертификатов следующих типов:

  • Сертификат ЦС (центр сертификации): сертификат ЦС — это цифровой сертификат, выданный центром сертификации (ЦС)
  • Сертификат EV (расширенная проверка): сертификат EV — это сертификат, соответствующий рекомендациям отраслевых сертификатов. При этом строка поиска в браузере станет зеленой и в ней будет отображаться название компании.
  • Wild карта Certificate: этот сертификат поддерживает любое количество поддоменов на основе *.site.com, где поддомен заменит *. Однако это не поддерживает site.com, поэтому если пользователи обращаются к вашему веб-сайту без ввода ведущего "www", дикий карта сертификат не будет охватывать это.
  • Самозаверяющие сертификаты: клиентские браузеры не доверяют этим сертификатам и предупреждают пользователя о том, что сертификат виртуальной службы не является частью цепочки доверия. Самозаверяющие сертификаты хорошо подходят для тестирования или сред, где клиентами управляют администраторы, которые могут безопасно обойти оповещения системы безопасности браузера. Не следует использовать самозаверяющие сертификаты для рабочих нагрузок в рабочей среде.

Дополнительные сведения см. в статье о настройке завершения сеансов TLS с помощью шлюза приложений.

Размер сертификата

Чтобы узнать о максимальном поддерживаемом размере сертификата TLS/SSL, ознакомьтесь с разделом Ограничения Шлюза приложений.

Сквозное шифрование TLS

Иногда незашифрованное соединение с внутренними серверами необходимо запретить. Это может быть связано с требованиями безопасности и соответствия или с тем, что приложение может принимать только безопасные подключения. Шлюз приложений Azure обеспечивает сквозное шифрование TLS, позволяющее выполнить такие требования.

Сквозной протокол TLS позволяет шифровать и безопасно передавать конфиденциальные данные на внутренние серверы при использовании функций балансировки нагрузки уровня 7 для Шлюза приложений. К ним относится применение сходства сеансов на основе файлов cookie, маршрутизация на основе URL-адресов, поддержка маршрутизации на основе сайтов и возможность перезаписи или внедрения заголовков X-Forwarded-* и т. п.

Если на Шлюзе приложений настроен сквозной режим связи TLS, он завершает сеансы TLS пользователей на шлюзе и расшифровывает пользовательский трафик. Затем он применяет настроенные правила и выбирает подходящий экземпляр внутреннего пула для передачи трафика в него. Затем Шлюз приложений инициирует новое TLS-подключение ко внутреннему серверу и повторно шифрует данные с помощью сертификата открытого ключа внутреннего сервера, прежде чем передать запрос в серверную часть. Любой ответ веб-сервера проходит через тот же процесс на пути к пользователю. Чтобы включить сквозной режим TLS, следует задать значение HTTPS для параметра протокола в настройках HTTP внутреннего сервера, который применяется к внутреннему пулу.

В Шлюз приложений шлюзах SKU версии 1 политика TLS применяет версию TLS только к интерфейсным трафику и определенным шифрам как к внешним, так и к целевым объектам серверной части. В Шлюз приложений шлюзах SKU версии 2 политика TLS применяется только к интерфейсным трафику, внутренние подключения TLS всегда будут согласованы через TLS 1.0 с версиями TLS 1.2.

Шлюз приложений обменивается данными только с этими серверными серверами, у которых есть список разрешенных сертификатов с Шлюз приложений или с сертификатами, подписанными известными центрами сертификации, а CN сертификата соответствует имени узла в параметрах серверной части HTTP. К ним относятся доверенные службы Azure, такие как Служба приложений Azure и ее веб-приложения, а также Управление API Azure.

Если сертификаты членов в серверном пуле не подписаны известными центрами сертификации, то каждый экземпляр в серверном пуле с поддержкой end to end TLS должен быть настроен с помощью сертификата, чтобы разрешить безопасное взаимодействие. Добавление сертификата гарантирует, что шлюз приложений взаимодействует только с известными экземплярами серверной части. тем самым защищая сквозной обмен данными.

Примечание.

Сертификат, добавленный в настройки внутреннего трафика HTTP для проверки подлинности внутренних серверов, может совпадать с сертификатом, добавленным в прослушиватель для завершения сеанса TLS на шлюзе приложений, или отличаться (для большей безопасности).

end to end TLS scenario

В этом примере запросы, в которых используется TLS1.2, направляются на внутренние серверы в пул 1 с помощью сквозного шифрования TLS.

Сквозное шифрование TLS и список разрешенных сертификатов

Шлюз приложений обменивается данными только с этими серверными серверами, у которых есть список разрешенных сертификатов с Шлюз приложений или с сертификатами, подписанными известными центрами сертификации, а CN сертификата соответствует имени узла в параметрах серверной части HTTP. Процесс настройки сквозного шифрования TLS несколько отличается для разных версий Шлюза приложений. В следующем разделе описываются отдельные версии.

Сквозное шифрование TLS с номером SKU версии 1

Чтобы обеспечить сквозное шифрование TLS на внутренних серверах и маршрутизацию запросов к ним на Шлюзе приложений, необходимо воспользоваться зондами работоспособности и получить ответ, который ее подтверждает.

Для зондов работоспособности HTTPS Шлюз приложений с номером SKU версии 1 использует точное совпадение сертификата проверки подлинности (открытого ключа сертификата внутреннего сервера, а не корневого сертификата), отправленного в параметры HTTP.

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

Примечание.

Проверка подлинности и настройка доверенных корневых сертификатов не требуются для доверенных служб Azure, таких как служба приложение Azure. По умолчанию они считаются доверенными.

Сквозное шифрование TLS с номером SKU версии 2

Сертификаты проверки подлинности устарели и заменены доверенными корневыми сертификатами в номере SKU Шлюза приложений версии 2. Они действуют идентично сертификатам проверки подлинности, за исключением нескольких ключевых различий:

  • Сертификаты, подписанные хорошо известными центрами сертификации, цН которых соответствует имени узла в параметрах серверной части HTTP, не требуют дополнительного шага для завершения работы TLS.

    Например, если сертификаты серверной части выданы хорошо известным центром сертификации и имеют общее имя contoso.com, а в поле узла в параметрах HTTP внутреннего сервера также указано значение contoso.com, дополнительные действия не требуются. Для протокола в параметрах HTTP серверной части можно задать HTTPS. Таким образом, и для зонда работоспособности, и для пути данных будет включен TLS. При использовании Службы приложений Azure или других веб-служб Azure в качестве внутреннего сервера они имеют неявное доверие. В этом случае для сквозного шифрования TLS дополнительные шаги не требуются.

Примечание.

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

  • Если сертификат внутреннего сервера является самозаверяющим или подписан неизвестным центром сертификации/посредниками, то для включения сквозного протокола TLS в шлюзе приложений версии 2 необходимо загрузить доверенный корневой сертификат. Шлюз приложений будет взаимодействовать только с серверными частями, корневой сертификат сертификата сервера которых совпадает с одним из сертификатов из списка доверенных корневых сертификатов в параметре HTTP серверной части, который связан с пулом.

  • Помимо соответствия корневому сертификату Шлюз приложений версии 2 также проверяет, соответствуют ли параметры узла, указанные в параметрах HTTP внутреннего сервера, обычному имени, представленному сертификатом TLS/SSL внутреннего сервера. При попытке установить TLS-подключение к серверной части Шлюз приложений версии 2 задает расширение SNI узлу, указанному в параметрах HTTP серверной части.

  • Если в серверных параметрах HTTP вместо настроено получение имени узла от серверного целевого объекта вместо поля узла, в заголовке SNI всегда будет указано полное доменное имя внутреннего пула, и общее имя в TLS/SSL-сертификате внутреннего сервера должно совпадать с его полным доменным именем. Участники серверного пула с IP-адресами в этом сценарии не поддерживаются.

  • Корневой сертификат — это закодированный в Base64 корневой сертификат из списка сертификатов внутреннего сервера.

Различия SNI в номере SKU версии 1 и 2

Как упоминалось ранее, шлюз приложений завершает трафик TLS от клиента на прослушивателе Шлюза приложений (назовем его внешним подключением), расшифровывает трафик, применяет необходимые правила для определения внутреннего сервера, на который пересылается запрос, и устанавливает новый сеанс TLS с внутренним сервером (назовем его внутренним подключением).

В следующих таблицах описаны различия в SNI для номеров SKU версии 1 и 2 с точки зрения внутренних и внешних подключений.

Внешнее TLS-подключение (от клиента к шлюзу приложений)

Сценарий Версия 1 Версия 2
Клиент указывает заголовок SNI, и все прослушиватели для нескольких сайтов включены с флагом "Требовать SNI" Возвращает соответствующий сертификат, а если сайт не существует (в соответствии со значением server_name), подключение сбрасывается. Возвращает соответствующий сертификат, если он доступен. В противном случае возвращает сертификат первого прослушивателя HTTPS в соответствии с порядком, указанным в правилах маршрутизации запросов, связанных с прослушивателями HTTPS.
Клиент не указывает заголовок SNI, и все заголовки для нескольких сайтов включены с флагом "Требовать SNI" Сбрасывает подключение. Возвращает сертификат первого прослушивателя HTTPS в соответствии с порядком, указанным в правилах маршрутизации запросов, связанных с прослушивателями HTTPS.
Клиент не указал заголовок SNI, и имеется базовый прослушиватель, для которого настроен сертификат Возвращает клиенту сертификат, настроенный в основном прослушивателе (заданный по умолчанию или резервный). Возвращает сертификат, настроенный в основном прослушивателе

Совет

Флаг SNI можно настроить с помощью PowerShell или с помощью шаблона ARM. Дополнительные сведения см. в статье RequireServerNameIndication и Краткое руководство. Прямой веб-трафик с помощью шаблона ARM Шлюз приложений Azure.

Серверное подключение TLS (от шлюза приложений к внутреннему серверу)

Для трафика зонда

Сценарий Версия 1 Версия 2
Заголовок SNI (server_name) во время подтверждения TLS в качестве полного доменного имени Указывается в качестве полного доменного имени из внутреннего пула. Согласно RFC 6066, адреса IPv4 и IPv6 не разрешены в имени узла SNI.
Примечание. Полное доменное имя в серверном пуле должно разрешать DNS на IP-адрес внутреннего сервера (общедоступный или частный)		 Заголовок SNI (server_name) задается в качестве имени узла, полученного из пользовательского зонда, связанного с параметрами HTTP (если они настроены), имени узла, указанного в параметрах HTTP, или полного доменного имени, указанного во внутреннем пуле. Порядок приоритета — это пользовательский пул параметров http пробы > > .
Примечание. Если имена узлов, настроенные в параметрах HTTP и настраиваемой пробе, отличаются, то в соответствии с приоритетом SNI будет задано в качестве имени узла из пользовательской пробы.
Адрес внутреннего пула является IP-адресом (в версии 1), или имя узла пользовательского зонда настроено как IP-адрес (в версии 2) Заголовок SNI (server_name) не будет задан.
Примечание. В этом случае сервер сервер должен иметь возможность возвращать сертификат по умолчанию или резервному сертификату, и это должно быть разрешено в параметрах HTTP в сертификате проверки подлинности. Если на внутреннем сервере не настроен сертификат (по умолчанию или резервной), а ожидается SNI, сервер может сбросить подключение, что приведет к сбою зонда.		 Учитывая порядок приоритетности, упомянутый ранее, если имя узла — это IP-адрес, SNI не устанавливается в соответствии с RFC 6066.
Примечание. SNI также не будет задано в пробах версии 2, если настраиваемая проба не настроена и имя узла не задано в параметрах HTTP или серверном пуле.

Примечание.

Если настраиваемая проба не настроена, Шлюз приложений отправляет пробу по умолчанию в этом формате — <протокол>://127.0.0.1:<port>/. Например, для пробы HTTPS по умолчанию он будет отправлен как https://127.0.0.1:443/. Обратите внимание, что 127.0.0.1, упоминание здесь, используется только в качестве заголовка узла HTTP, и как указано в RFC 6066, не будет использоваться в качестве заголовка SNI. Дополнительные сведения об ошибках зондов работоспособности см. в руководстве по устранению неполадок, связанных с работоспособностью внутреннего сервера.

Для трафика в реальном времени

Сценарий Версия 1 Версия 2
Заголовок SNI (server_name) во время подтверждения TLS в качестве полного доменного имени Указывается в качестве полного доменного имени из внутреннего пула. Согласно RFC 6066, адреса IPv4 и IPv6 не разрешены в имени узла SNI.
Примечание. Полное доменное имя в серверном пуле должно разрешать DNS на IP-адрес внутреннего сервера (общедоступный или частный)		 Заголовок SNI (server_name) задается в качестве имени узла из параметров HTTP, в противном случае, если выбран параметр PickHostnameFromBackendAddress или если имя узла не упоминание, оно будет задано как полное доменное имя в конфигурации внутреннего пула.
Если внутренний пул является IP-адресом или именем узла не задан в параметрах HTTP. SNI не будет задано в формате RFC 6066, если запись внутреннего пула не является полным доменным именем Заголовком SNI будет имя узла из входного полного доменного имени, полученного от клиента. При этом общее имя сертификата внутреннего сервера должно соответствовать этому имени узла.
Имя узла не указано в http-Параметры, но полное доменное имя указывается в качестве целевого объекта для члена внутреннего пула. Заголовком SNI будет имя узла из входного полного доменного имени, полученного от клиента. При этом общее имя сертификата внутреннего сервера должно соответствовать этому имени узла. Заголовком SNI будет имя узла из входного полного доменного имени, полученного от клиента. При этом общее имя сертификата внутреннего сервера должно соответствовать этому имени узла.

Следующие шаги

Ознакомившись со сквозным шифрованием TLS, настройте сквозное шифрование TLS в Шлюзе приложений с помощью PowerShell, чтобы создать шлюз приложений, использующий сквозное шифрование TLS.