Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается настройка Шлюза приложений Azure с помощью службы приложений Azure с помощью частных конечных точек для защиты трафика. В этой статье также рассматриваются рекомендации по использованию конечных точек службы и интеграции с внутренними и внешними средами службы приложений. В статье описывается, как настроить ограничения доступа на сайте системы управления версиями (SCM).
Интеграция с Службой приложений
Вы можете использовать частные конечные точки для защиты трафика между Шлюз приложений и приложением Служба приложений. Необходимо убедиться, что шлюз приложений может использовать систему доменных имен (DNS) для разрешения частного IP-адреса приложений службы приложений. Кроме того, вы можете использовать частный IP-адрес в серверном пуле и переопределить имя узла в параметрах HTTP.
#B0 #A1 Диаграмма, показывающая направляемый через частную конечную точку трафик к шлюзу приложений (Application Gateway) и экземплярам приложений в службе приложений (App Service). #A2 #C3
Шлюз приложений кэширует результаты поиска DNS. Если вы используете полные доменные имена (FQDN) и используете поиск DNS, чтобы получить частный IP-адрес, может потребоваться перезапустить шлюз приложений, если обновление DNS или ссылка на частную зону DNS Azure произошла после настройки внутреннего пула.
Чтобы перезапустить шлюз приложений, остановите и запустите его с помощью Azure CLI:
az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw
Узнайте больше о настройке приложения Служба приложений с частной конечной точкой.
Рекомендации по использованию конечных точек службы
В качестве альтернативы использованию частных конечных точек можно использовать конечные точки службы для защиты трафика из шлюза приложений. С помощью конечных точек службы можно разрешить трафик только из определенной подсети в виртуальной сети Azure и заблокировать все остальное. В следующем сценарии вы используете эту функцию, чтобы убедиться, что экземпляр Служба приложений может получать трафик только из определенного шлюза приложений.
#B0 #A1 Диаграмма, показывающая, как интернет-трафик идет к шлюзу приложений в виртуальной сети Azure, а затем проходит через брандмауэр к экземплярам приложений в Azure App Service. #A2 #C3
Эта конфигурация состоит из двух частей, помимо создания экземпляра приложения Службы приложений и шлюза приложений.
Первая часть — включение конечных точек службы в подсети виртуальной сети, в которой развернут шлюз приложений. Конечные точки службы гарантируют, что весь сетевой трафик, покидающий подсеть, к Службе приложений, помечен определенным идентификатором подсети.
Во-вторых, необходимо задать ограничение доступа для конкретного веб-приложения, чтобы убедиться, что разрешен только трафик, помеченный этим идентификатором подсети. Ограничение доступа можно настроить с помощью различных инструментов в зависимости от вашего предпочтения.
На портале Azure выполните четыре действия, чтобы создать и настроить интеграцию службы приложений и шлюза приложений. Если у вас уже есть ресурсы, первые шаги можно пропустить.
- Создайте экземпляр Службы приложений, используя одно из Кратких руководств в документации по Службе приложений. Одним из примеров является краткое руководство по .NET Core.
- Создайте шлюз приложений с помощью краткого руководства по порталу, но пропустите раздел о добавлении целевых объектов серверной части.
- Настройте Службу приложений как back end в Application Gateway, но пропустите раздел об ограничении доступа.
- Создайте ограничение доступа с помощью конечных точек сервиса.
Теперь вы можете получить доступ к Службе приложений через Шлюз приложений. Если вы пытаетесь получить доступ непосредственно к службе приложений, ожидается сообщение об ошибке 403 HTTP, которая говорит, что веб-приложение блокирует доступ.
Соображения о внутренней среде App Service
Внутренняя среда службы приложений не выставляется в интернет. Трафик между экземпляром и шлюзом приложений уже изолирован в пределах виртуальной сети. Вы можете настроить внутреннюю среду App Service и интегрировать её со шлюзом приложений с помощью портала Azure.
Если вы хотите убедиться, что только трафик из подсети шлюза приложений достигает среды службы приложений, можно настроить группу безопасности сети, которая влияет на все веб-приложения в среде службы приложений. Для группы безопасности сети можно указать диапазон IP-адресов подсети и порты (80/443).
Чтобы изолировать трафик для отдельного веб-приложения, необходимо использовать ограничения доступа на основе IP-адресов, так как конечные точки сервиса не работают с App Service Environment. IP-адрес должен быть частным IP-адресом шлюза приложений.
Соображения по внешней среде App Service
Внешняя среда службы приложений Azure имеет общедоступный балансировщик нагрузки, подобно мультитенантным приложениям службы приложений. Конечные точки службы не работают для среды служб приложений. В среде службы приложений можно использовать ограничения доступа на основе IP-адресов с помощью общедоступного IP-адреса шлюза приложений. Чтобы создать внешнюю среду службы приложений, используя портал Azure, можно использовать краткое руководство.
Вы также можете добавить частные конечные точки в приложения, размещенные во внешней среде службы приложений.
Рекомендации по сайту Kudu/SCM
Сайт SCM, также известный как Kudu, является сайтом администратора, который существует для каждого веб-приложения. Невозможно использовать обратный прокси-сервер для сайта SCM. Скорее всего, вы также хотите заблокировать его на отдельные IP-адреса или определенную подсеть.
Если вы хотите использовать те же ограничения доступа, что и основной сайт, можно наследовать параметры с помощью следующей команды:
az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site
Если вы хотите добавить отдельные ограничения доступа для сайта SCM, можно использовать --scm-site
флаг:
az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16
Рекомендации по использованию домена по умолчанию
Настройка Шлюза приложений для переопределения имени узла и использования домена по умолчанию служб приложений (обычно azurewebsites.net
) — это самый простой способ настройки интеграции. Для этого не требуется настройка личного домена и сертификата в Служба приложений.
Сохранение имени узла обсуждает общие соображения по переопределению исходного имени узла. В службе приложений необходимо обратить внимание на эту конфигурацию в двух сценариях.
Проверка подлинности
При использовании функции проверки подлинности в службе приложений (также называемой Easy Auth), ваше приложение обычно перенаправляется на страницу входа. Так как Служба приложений не знает исходное имя узла запроса, перенаправление выполняется по имени домена по умолчанию и обычно приводит к ошибке.
Чтобы обойти перенаправление по умолчанию, можно настроить проверку подлинности для проверки перенаправленного заголовка и адаптации домена перенаправления к исходному домену. Шлюз приложений использует заголовок с именем X-Original-Host
. Используя файловую конфигурацию для настройки проверки подлинности, можно настроить службу приложений для адаптации к исходному имени узла.
Добавьте эту конфигурацию в файл конфигурации:
{
...
"httpSettings": {
"forwardProxy": {
"convention": "Custom",
"customHostHeaderName": "X-Original-Host"
}
}
...
}
Сходство сеансов
В развертываниях с несколькими экземплярами привязка сессий гарантирует, что клиентские запросы направляются в тот же экземпляр на протяжении всего сеанса. Чтобы настроить сопоставление сеансов, можно изменить домен cookie в заголовке запроса, поступающем через обратный прокси-сервер. Установив прокси-сервер привязки сеанса на true
, привязка сеанса ищет X-Original-Host
или X-Forwarded-Host
и адаптирует домен cookie в соответствии с доменом, найденным в этом заголовке. При рекомендуемом использовании функции привязки сеансов к прокси-серверу необходимо настроить ограничения доступа на сайте, чтобы убедиться, что трафик поступает из вашего обратного прокси-сервера.
Вы также можете настроить clientAffinityProxyEnabled
с помощью следующей команды:
az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true
Связанный контент
- Узнайте больше о средах службы приложений.
- Узнайте, как защитить веб-приложение с помощью брандмауэра веб-приложений Azure.
- Выполните учебное пособие по развертыванию безопасного, устойчивого сайта с пользовательским доменом в службе приложений с помощью Azure Front Door или Шлюза приложений.