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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полное шифрование TLS с SKU версии 1.

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

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

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

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

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

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

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

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

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

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

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

Различия в SNI в SKU версиях 1 и 2

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

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

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

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

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

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

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

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