Предоставление Azure Spring Apps через обратный прокси-сервер

При размещении приложений или микрослужб в Azure Spring Apps вам не всегда требуется публиковать их непосредственно в Интернете. Вместо этого может потребоваться предоставить их через обратный прокси-сервер. Такой подход позволяет разместить службу перед приложениями. Служба может определять перекрестные функции, такие как возможности брандмауэра веб-приложения (WAF), чтобы защитить приложения, балансировку нагрузки, маршрутизацию, фильтрацию запросов и ограничение скорости.

При развертывании обычной службы обратного прокси-сервера, например Шлюз приложений Azure или Azure Front Door перед Azure Spring Apps, необходимо убедиться, что приложения можно получить только через обратный прокси-сервер. Эта защита помогает предотвратить попытку вредоносных пользователей обойти ограничения регулирования WAF или обойти их.

Защита от атак DDoS Azure в сочетании с рекомендациями по проектированию приложений предоставляет расширенные функции защиты от атак DDoS. Необходимо включить защиту от атак DDOS Azure в любой виртуальной сети периметра.

В этой статье описывается, как применять ограничения доступа, чтобы приложения, размещенные в Azure Spring Apps, доступны только через службу обратного прокси-сервера. Рекомендуемый способ применения этих ограничений зависит от развертывания экземпляра Azure Spring Apps и используемого обратного прокси-сервера. Это разные точки, которые следует учитывать в зависимости от того, развертывается ли вы в виртуальной сети или за ее пределами. В этой статье содержатся сведения о четырех сценариях.

• Разверните Azure Spring Apps в виртуальной сети и частный доступ к приложениям из сети.

  • У вас есть контроль над виртуальной сетью, в которой выполняются приложения. Используйте собственные сетевые функции Azure, такие как группы безопасности сети (NSG), чтобы заблокировать доступ, чтобы разрешить только обратный прокси-сервер.

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

  • Вы не можете использовать Azure Front Door напрямую, так как он не может связаться с экземпляром Azure Spring Apps в частной виртуальной сети. Azure Front Door может подключаться к серверным службам только через общедоступный IP-адрес или через службы, использующие частную конечную точку. Если у вас есть развертывание Azure Spring Apps с несколькими регионами и требуется глобальная балансировка нагрузки, вы по-прежнему можете предоставлять экземпляры Azure Spring Apps через Шлюз приложений. Чтобы достичь этого сценария, вы размещаете Azure Front Door перед Шлюз приложений. Этот подход описан в сценарии 2 далее в этой статье.

• Разверните Azure Spring Apps за пределами виртуальной сети и опубликуйте приложения в Интернете напрямую, если назначить им конечную точку.

  • Вы не управляете сетью и не можете использовать группы безопасности сети для ограничения доступа. Для доступа к приложениям требуется только обратный прокси-сервер в Azure Spring Apps.

  • Так как ваши приложения общедоступны, вы можете использовать Шлюз приложений или Azure Front Door в качестве обратного прокси-сервера. Подход Шлюз приложений описан в сценарии 3 далее в этой статье. Подход Azure Front Door описан в сценарии 4 далее в этой статье.

  • При необходимости можно использовать сочетание обоих подходов. Если вы используете оба Шлюз приложений и Azure Front Door, используйте одинаковые ограничения доступа между двумя обратными прокси-серверами, которые используются в сценарии 2.

Сравнение сценариев

В следующей таблице представлено краткое сравнение четырех сценариев конфигурации обратного прокси-сервера для Azure Spring Apps. Полные сведения о каждом сценарии см. в соответствующем разделе этой статьи.

Развертывание в виртуальной сети

При развертывании Azure Spring Apps в виртуальной сети используется две подсети:

• Подсеть среды выполнения службы, содержащая соответствующие сетевые ресурсы
• Подсеть приложений, в которую размещается код

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

Каждое приложение, которое вы хотите предоставить через обратный прокси-сервер, должно иметь назначенную конечную точку, чтобы обратный прокси-сервер смог связаться с приложением в виртуальной сети. Для каждого приложения также следует сопоставить пользовательские домены , которые он использует, чтобы избежать переопределения заголовка HTTP Host в обратном прокси-сервере и сохранить исходное имя узла нетронутым. Этот метод позволяет избежать таких проблем, как неработающие файлы cookie или URL-адреса перенаправления, которые не работают должным образом. Дополнительные сведения см. в разделе "Сохранение имени узла".

Сценарий 1. Использование Шлюз приложений в качестве обратного прокси-сервера

Сценарий 1 описывает, как предоставить приложениям общедоступные доступ к Интернету с помощью Шлюз приложений, а затем применить соответствующие ограничения доступа, чтобы заблокировать его.

На следующей схеме показана архитектура сценария 1:

Скачайте файл Visio для этой архитектуры.

Когда Шлюз приложений находится перед экземпляром Azure Spring Apps, вы используете назначенную конечную точку приложения Spring Cloud Gateway в качестве внутреннего пула. Пример конечной точки: myspringcloudservice-myapp.private.azuremicroservices.io. Конечная точка разрешает частный IP-адрес в подсети среды выполнения службы. Таким образом, чтобы ограничить доступ, вы можете разместить группу безопасности сети в подсети среды выполнения службы со следующими правилами безопасности для входящего трафика (предоставляя правило запрета наименьшим приоритетом):

Конфигурация сценария 1 гарантирует, что подсеть среды выполнения службы разрешает трафик только из следующих источников:

• Выделенная подсеть Шлюз приложений
• Подсеть приложений (двунаправленное взаимодействие между двумя подсетями Azure Spring Apps требуется.)
• Подсистема балансировки нагрузки Azure (которая является общим требованием к платформе Azure)

Все остальные трафик заблокированы.

Сценарий 2. Использование Azure Front Door и Шлюз приложений в качестве обратного прокси-сервера

Как упоминалось ранее, вы не можете разместить Azure Front Door непосредственно перед Azure Spring Apps, так как он не может связаться с частной виртуальной сетью. (Azure Front Door Standard или Premium может подключаться к частным конечным точкам в виртуальной сети, но Azure Spring Apps в настоящее время не предлагает поддержку частных конечных точек.) Если вы по-прежнему хотите использовать Azure Front Door, например для глобальной балансировки нагрузки между несколькими экземплярами Azure Spring Apps в разных регионах Azure, вы можете по-прежнему предоставлять приложения через Шлюз приложений. Чтобы достичь этого сценария, вы размещаете Azure Front Door перед Шлюз приложений.

На следующей схеме показана архитектура сценария 2:

Скачайте файл Visio для этой архитектуры.

Конфигурация 2 сценария 2 реализует ограничения доступа между Шлюз приложений и Azure Spring Apps таким же образом, как и сценарий 1. Группа безопасности сети размещается в подсети среды выполнения службы с соответствующими правилами.

В сценарии 2 также необходимо убедиться, что Шлюз приложений принимает трафик, поступающий только из экземпляра Azure Front Door. В документации по Azure Front Door объясняется , как заблокировать доступ к серверной части, чтобы разрешить только трафик Azure Front Door. Если внутренний интерфейс Шлюз приложений, это ограничение можно реализовать следующим образом:

• В подсети Шлюз приложений создайте группу безопасности сети, чтобы разрешить только трафик с тегом AzureFrontDoor.Backend службы (ничего, кроме Azure Front Door, может достичь Шлюз приложений). Не забудьте также включить другие необходимые теги службы, как описано в ограничениях NSG для Шлюз приложений.
• Создайте настраиваемое правило WAF в Шлюз приложений, чтобы убедиться, X-Azure-FDID что заголовок HTTP задан для конкретного идентификатора экземпляра Azure Front Door. Этот метод гарантирует, что экземпляры Azure Front Door другой организации, использующие одни и те же диапазоны IP-адресов, могут получить доступ к вашему Шлюз приложений экземпляру.

Развертывание за пределами виртуальной сети

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

Использование Spring Cloud Gateway для предоставления и защиты приложений

Чтобы удалить ответственность за управление доступом от разработчиков отдельных приложений, можно применить перекрестные ограничения с помощью Spring Cloud Gateway. Spring Cloud Gateway — это часто используемый проект Spring, который можно развернуть в Azure Spring Apps так же, как и любое другое приложение. Используя Spring Cloud Gateway, вы можете хранить собственные приложения в экземпляре Azure Spring Apps и обеспечить доступ только через общее приложение Spring Cloud Gateway. Затем вы настроите это приложение с необходимыми ограничениями доступа с помощью предикатов маршрутов, которые являются встроенной функцией Spring Cloud Gateway. Предикаты маршрутов могут использовать различные атрибуты входящего HTTP-запроса, чтобы определить, следует ли направлять запрос в серверное приложение или отклонять его. Предикат может использовать такие атрибуты, как IP-адрес клиента, метод запроса или путь, заголовки HTTP и т. д.

Этот шаблон часто используется. В целях этой статьи предполагается, что вы предоставляете приложения через Spring Cloud Gateway. Мы ожидаем, что вы используете предикаты маршрута для настройки необходимых ограничений доступа, чтобы гарантировать, что разрешены только запросы от обратного прокси-сервера. Даже если вы не используете Шлюз Spring Cloud, применяются те же общие принципы. Однако необходимо создать собственные возможности фильтрации запросов в приложения на основе того же X-Forwarded-For заголовка HTTP, который описан далее в этой статье.

Описание работы Spring Cloud Gateway выходит за рамки этой статьи. Это высоко гибкая служба, которую можно настроить с помощью кода или конфигурации. Для простоты в этой статье описывается только чисто управляемый конфигурацией подход, который не требует изменений кода. Этот подход можно реализовать, включив традиционный application.properties или application.yml файл в развернутое приложение Spring Cloud Gateway. Вы также можете реализовать подход с помощью сервера конфигурации в Azure Spring Apps , который внешний файл конфигурации в репозиторий Git. В следующих примерах мы реализуем подход с синтаксисом application.yml YAML, но аналогичный application.properties синтаксис также работает.

Маршрутизация запросов к приложениям

По умолчанию, когда ваше приложение в Azure Spring Apps не назначает ей конечную точку или личный домен, он недоступен извне. Когда приложение регистрируется в реестре служб Spring Cloud, Spring Cloud Gateway может обнаружить приложение, чтобы использовать правила маршрутизации для пересылки трафика в нужное целевое приложение.

В результате единственное приложение, которому необходимо назначить конечную точку в Azure Spring Apps, — это приложение Spring Cloud Gateway. Эта конечная точка делает ее доступной извне. Не следует назначать конечную точку другим приложениям. В противном случае приложения можно получить напрямую, а не через Шлюз Spring Cloud, что, в свою очередь, позволяет обойти обратный прокси-сервер.

Простой способ предоставления всех зарегистрированных приложений через Spring Cloud Gateway — использовать указатель определения маршрута DiscoveryClient следующим образом:

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

Кроме того, вы можете выборочно предоставлять определенные приложения через Spring Cloud Gateway, определив маршруты для конкретных приложений:

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

При использовании подхода указателя обнаружения и явных определений маршрутов можно использовать предикаты маршрутов для отклонения недопустимых запросов. В этом случае мы используем эту функцию для блокировки запросов, которые не приходят из ожидаемого обратного прокси-сервера, который находится перед Azure Spring Apps.

Ограничение доступа с помощью заголовка X-Forwarded-For HTTP

При развертывании приложения в Azure Spring Apps http-клиент или обратный прокси-сервер не подключается непосредственно к приложению. Сетевой трафик сначала проходит через внутренний контроллер входящего трафика.

Из-за дополнительной службы IP-адрес клиента прямой сети всегда является внутренним компонентом Azure Spring Apps. IP-адрес никогда не является логическим клиентом, например обратным прокси-сервером, который вы ожидаете вызвать приложение. Ip-адрес клиента нельзя использовать для ограничений доступа. Вы также не можете использовать встроенный RemoteAddr предикат маршрута Spring Cloud для фильтрации запросов, так как он использует IP-адрес клиента по умолчанию.

К счастью, Azure Spring Apps всегда добавляет IP-адрес X-Forwarded-For логического клиента в заголовок HTTP в запросе в приложение. Последнее (правое значение) заголовка X-Forwarded-For всегда содержит IP-адрес логического клиента.

Чтобы отфильтровать запросы на основе заголовка X-Forwarded-For , можно использовать встроенный XForwarded Remote Addr предикат маршрута. Этот предикат позволяет настроить список IP-адресов или диапазонов IP-адресов обратного прокси-сервера, которые разрешены в качестве правильного значения.

Настройка приложения для просмотра правильного имени узла и URL-адреса запроса

При использовании Spring Cloud Gateway необходимо учитывать важный фактор. Spring Cloud Gateway задает заголовок HTTP Host для исходящего запроса на внутренний IP-адрес экземпляра приложения, например Host: 10.2.1.15:1025. Имя узла запроса, которое отображает код приложения, больше не является исходным именем узла запроса, отправленного браузером, например contoso.com. В некоторых случаях этот результат может привести к проблемам, таким как сломанные файлы cookie или перенаправление URL-адресов, которые не работают должным образом. Дополнительные сведения об этих типах проблем и настройке обратной прокси-службы, например Шлюз приложений или Azure Front Door, чтобы избежать их, см. в разделе "Сохранение имен узла".

Spring Cloud Gateway предоставляет исходное имя узла в заголовкеForwarded. Он также задает другие заголовки, такие как X-Forwarded-Port, X-Forwarded-Protoи X-Forwarded-Prefix поэтому приложение может использовать их для восстановления исходного URL-адреса запроса. В приложениях Spring Framework эту конфигурацию можно реализовать автоматически, задав server.forward-headers-strategy параметр FRAMEWORK в свойствах приложения. (Не присвойте этому значению NATIVEзначение . В противном случае используются другие заголовки, которые не учитывают обязательный X-Forwarded-Prefix заголовок.) Дополнительные сведения см. в разделе "Запуск за внешним прокси-сервером". В этой конфигурации метод HttpServletRequest.getRequestURL принимает все эти заголовки в учетную запись и возвращает точный URL-адрес запроса, отправляемый браузером.

Сценарий 3. Использование Шлюз приложений с Spring Cloud Gateway

Сценарий 3 описывает использование Шлюз приложений в качестве обратного прокси-сервера для общедоступных приложений через конечную точку Шлюза Spring Cloud.

На следующей схеме показана архитектура сценария 3:

Скачайте файл Visio для этой архитектуры.

Когда Шлюз приложений находится перед экземпляром Azure Spring Apps, вы используете назначенную конечную точку приложения Spring Cloud Gateway в качестве внутреннего пула. Пример конечной точки: myspringcloudservice-mygateway.azuremicroservices.io. Так как Azure Spring Apps развертывается за пределами виртуальной сети, этот URL-адрес разрешается на общедоступный IP-адрес. Если серверный пул является общедоступной конечной точкой, Шлюз приложений использует внешний общедоступный IP-адрес для доступа к серверной службе.

Чтобы разрешить доступ только к запросам из экземпляра Шлюз приложений, можно настроить XForwarded Remote Addr предикат маршрута. Настройте предикат, чтобы разрешить только запросы с выделенного общедоступного IP-адреса Шлюз приложений, как показано в следующем примере:

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

Сценарий 4. Использование Azure Front Door с Spring Cloud Gateway

Сценарий 4 описывает использование Azure Front Door в качестве обратного прокси-сервера для общедоступных приложений через конечную точку Шлюза Spring Cloud.

На следующей схеме показана архитектура сценария 4.

Скачайте файл Visio для этой архитектуры.

Как и в случае 3, эта конфигурация использует общедоступный URL-адрес приложения Spring Cloud Gateway в качестве внутреннего пула или источника в Azure Front Door. Пример конечной точки: https://myspringcloudservice-mygateway.azuremicroservices.io.

Так как Azure Front Door — это глобальная служба с множеством пограничных расположений, она использует множество IP-адресов для взаимодействия с серверным пулом. В документации по Azure Front Door описывается , как заблокировать доступ к серверной части, чтобы разрешить только трафик Azure Front Door. Однако в этом сценарии вы не управляете сетью Azure, в которой развертываются ваши приложения. К сожалению, вы не можете использовать AzureFrontDoor.Backend тег службы, чтобы получить полный список исходящих IP-адресов Azure Front Door, которые гарантированно будут текущими. Вместо этого необходимо скачать диапазоны IP-адресов Azure и теги службы, найти AzureFrontDoor.Backend раздел и скопировать все диапазоны IP-адресов из addressPrefixes массива в XForwarded Remote Addr конфигурацию предиката маршрута.

Так как диапазоны IP-адресов Azure Front Door совместно используются для других организаций, вам также необходимо обеспечить блокировку доступа только к конкретному экземпляру Azure Front Door на основе X-Azure-FDID заголовка HTTP, содержащего уникальный Front Door ID. Доступ можно ограничить с помощью Header предиката маршрута, который отклоняет запрос, если указанный заголовок HTTP не имеет определенного значения.

В этом сценарии конфигурация предиката маршрута Spring Cloud шлюза может выглядеть следующим образом:

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "00112233-4455-6677-8899-aabbccddeeff"

Соавторы

Корпорация Майкрософт поддерживает это содержимое. Следующий участник разработал исходное содержимое.

Автор субъекта:

• Jelle Druyts | Главный инженер клиента

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

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

• Эталонная архитектура Azure Spring Apps
• Обязанности клиентов по запуску Azure Spring Apps в виртуальная сеть Azure

Связанные ресурсы

• Сохранение имени узла
• Параметры балансировки нагрузки
• Стиль архитектуры микрослужб