Сетевые возможности Службы приложений Azure

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

Существует два типа развертываний Службы приложений Azure.

• Мультитенантная общедоступная служба размещает планы службы приложений в ценовых категориях SKU "Бесплатный", "Общий", "Базовый", "Стандартный", "Премиум", "ПремиумV2", "ПремиумV3" и "ПремиумV4".
• В среде службы приложений с одним клиентом (ASE) планы службы приложений для изолированного SKU размещаются непосредственно в виртуальной сети Azure.

Используемые функции зависят от того, находитесь ли вы в мультитенантной среде или в ASE.

Сетевые функции многопользовательской службы приложений Azure

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

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

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

Варианты использования и функции

Для любого варианта использования существует несколько способов решения проблемы. Выбор наиболее подходящей функции иногда выходит за рамки сценария использования. В следующих примерах использования входящих функций рассматривается использование сетевых функций Службы приложений Azure для решения проблем с управлением трафиком, передаваемых в приложение:

В следующих сценариях использования показано, как можно применять сетевые функции службы приложения Azure для удовлетворения потребностей в исходящем доступе приложения.

Поведение сети по умолчанию

Единицы масштабирования Службы приложений Azure поддерживают несколько клиентов в каждом развертывании. При использовании планов ценовых категорий "Бесплатный" и "Общий" рабочие нагрузки клиентов размещаются на многоклиентских рабочих узлах. При использовании планов категории "Базовый" и выше рабочие нагрузки клиентов размещаются в выделенных ресурсах плана службы приложений. Если у вас есть план "Стандартной служебной программы приложений", все приложения этого плана работают в одном рабочем процессе. Если вы расширяете рабочий процесс, все приложения в этом плане службы приложений реплицируются на новом рабочем процессе для каждого экземпляра в вашем плане службы приложений.

Адреса для исходящего трафика

В значительной степени рабочие виртуальные машины делятся по планам службы приложений. Все планы "Бесплатный", "Общий", "Базовый", "Стандартный" и "Премиум" используют один и тот же рабочий тип виртуальной машины. План PremiumV2 использует другой тип виртуальной машины. PremiumV3 использует еще один тип виртуальной машины. И PremiumV4 использует еще один тип виртуальной машины.

При изменении семейства виртуальных машин вы получите другой набор исходящих адресов. При масштабировании с уровня "Стандартный" до PremiumV2 исходящие адреса изменяются. При масштабировании от PremiumV2 до PremiumV3 исходящие адреса изменяются. В некоторых более старых моделях масштабирования изменяются как входящие, так и исходящие адреса при переходе с уровня "Стандартный" на уровень PremiumV2.

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

В Службе приложений есть ряд конечных точек, которые используются для управления службой. Эти адреса публикуются в отдельном документе и также находятся в теге AppServiceManagement службы IP-адресов. Тег AppServiceManagement используется только в средах Службы приложений Azure, где необходимо разрешить такой трафик. Входящие адреса службы приложений отслеживаются в теге службы IP. Не существует тега службы IP-адресов, содержащего исходящие адреса, используемые Службой приложений.

Адрес, назначенный приложением

Функция присвоения адреса приложению является ответвлением возможности SSL на основе IP. Чтобы получить к нему доступ, настройте SSL с приложением. Эту функцию можно использовать для вызовов SSL на основе IP-адреса. Кроме того, ее можно использовать, чтобы предоставить приложению уникальный адрес.

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

• Поддержка требований SSL на основе IP-адреса для вашего приложения.
• Присвойте выделенный адрес вашему приложению, который не будет общим.

Чтобы узнать, как присвоить адрес приложению, см. статью Добавление сертификата TLS/SSL в Службу приложений Azure.

Ограничения доступа

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

Эта функция позволяет создать список правил разрешений и запретов, которые оцениваются в порядке приоритета. Аналогичным образом работает функция группы безопасности сети (NSG) в сети Azure. Эту функцию можно использовать в ASE или в многоклиентской службе. При использовании с ILB ASE, вы можете ограничить доступ из блоков частных адресов. Дополнительные сведения см. в статье Настройка ограничений доступа в Службе приложений Azure.

Частная конечная точка

Частная конечная точка — это сетевой интерфейс, который обеспечивает защищенное частное подключение к веб-приложению через приватный канал Azure. Частная конечная точка использует частный IP-адрес из виртуальной сети, чтобы добавить веб-приложение в эту сеть. Эта функция предназначена только для входящих потоков веб-приложения. Дополнительные сведения см. в статье Использование частных конечных точек для приложений Службы приложений.

Варианты использования этой функции

• Ограничение доступа к приложению из ресурсов виртуальной сети.
• Предоставьте доступ к вашему приложению на частном IP-адресе в вашей виртуальной сети.
• Защитите ваше приложение с помощью брандмауэра веб-приложений.

Частные конечные точки предотвращают кражу данных. Единственное, что можно достичь через частную конечную точку, — это приложение, с помощью которого она настроена.

Периметр безопасности сети

Периметр безопасности сети Azure (NSP) — это служба, которая предоставляет безопасный периметр для обмена данными служб Platform as a Service (PaaS). Эти службы PaaS могут взаимодействовать друг с другом в периметре. Они также могут взаимодействовать с ресурсами за пределами периметра с помощью общедоступных правил входящего и исходящего доступа.

Контроль соблюдения правил NSP в основном использует идентификационную безопасность. Этот подход не может быть полностью применен в службах платформ, таких как Служба приложений и функции, которые позволяют развертывать собственный код и использовать удостоверение для представления платформы. Если необходимо взаимодействовать со службами PaaS, которые являются частью NSP, добавьте интеграцию виртуальной сети в экземпляры службы приложений или функции. Обмен данными с ресурсами PaaS с помощью частных конечных точек.

Гибридные подключения

Гибридные подключения Службы приложений Azure позволяют приложениям выполнять исходящие вызовы к указанным конечным точкам TCP. Конечная точка может быть расположена в локальной среде, виртуальной сети или в любом другом местоположении, где разрешена передача исходящего трафика в Azure через порт 443. Чтобы использовать эту функцию, необходимо установить агент ретрансляции "Диспетчер гибридных подключений" на узле Windows Server 2012 или более поздней версии. Диспетчер гибридных подключений должен иметь доступ к Azure Relay через порт 443. Вы можете скачать Диспетчер гибридных подключений из интерфейса гибридных подключений службы приложений на портале.

В основе гибридных подключений службы приложений лежит функция гибридных подключений Azure Relay. Служба приложений использует особую форму функции, которая поддерживает только отправку исходящих вызовов из приложения на узел и порт TCP. Этот узел и порт должны быть разрешены только на узле, где установлен Диспетчер гибридных подключений.

Когда приложение в службе App Service, в Microsoft Azure, выполняет поиск DNS на узле и порте, указанных в ваших параметрах гибридного подключения, трафик автоматически перенаправляется через это гибридное подключение и выходит через Диспетчер гибридных подключений. Дополнительные сведения см. в разделе App Service Hybrid Connections.

Эта функция обычно используется в следующих целях.

• Доступ к ресурсам в частных сетях, которые не подключены к Azure с помощью VPN или ExpressRoute.
• Поддержка миграции локальных приложений в Службу приложений Azure без перемещения вспомогательных баз данных.
• Предоставляйте доступ с улучшенной безопасностью к единственному узлу и порту для каждого гибридного подключения. Большинство сетевых функций открывают доступ к сети. С помощью гибридных подключений можно получить доступ только к одному узлу и порту.
• Охват сценариев, не охваченных другими методами исходящего подключения.
• Разработка в Службе приложений Azure должна осуществляться таким образом, чтобы приложения могли с легкостью использовать локальные ресурсы.

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

Гибридные подключения App Service не осведомлены о том, что вы делаете поверх них. Его можно использовать для доступа к базе данных, веб-службе или произвольному сокету TCP на мейнфрейме. По сути, она служит для туннелирования пакетов TCP.

Гибридные подключения популярны для разработки. Его также можно использовать в рабочих приложениях. Эта функция отлично подходит для получения доступа к веб-службе или базе данных, но не предназначена для ситуаций, где предполагается создание множества подключений.

Интеграция виртуальной сети

Интеграция виртуальной сети в службе приложений позволяет вашему приложению выполнять исходящие запросы в виртуальную сеть Azure.

Функция интеграции виртуальной сети позволяет разместить серверную часть приложения в подсети в виртуальной сети Resource Manager. Виртуальная сеть должна находиться в том же регионе, что и приложение. Эта функция недоступна из среды службы приложений, которая уже находится в виртуальной сети. Варианты использования этой функции

• Доступ к ресурсам в виртуальных сетях Azure Resource Manager в одном регионе.
• Доступ к ресурсам в одноранговых виртуальных сетях, в том числе подключения между регионами.
• Доступ к ресурсам, защищенным с помощью конечных точек службы.
• Доступ к ресурсам, доступным через подключения ExpressRoute или VPN.
• Доступ к ресурсам в частных сетях без необходимости и стоимости шлюза виртуальной сети.
• Помощь в обеспечении безопасности всего исходящего трафика.
• Принудительное туннелирование всего исходящего трафика.

Дополнительные сведения см. в статье Интеграция виртуальной сети Службы приложений.

Интеграция виртуальной сети с обязательным использованием шлюза

Интеграция виртуальной сети с требованием шлюза была первой версией интеграции виртуальной сети в Службе приложений. Эта функция использует VPN типа "точка-сайт" для подключения хоста, на котором выполняется приложение, к шлюзу виртуальной сети в вашей виртуальной сети. При настройке функции приложение получает один из адресов, назначенных по принципу point-to-site, который назначается каждому экземпляру.

Необходимая интеграция шлюза позволяет подключаться непосредственно к виртуальной сети в другом регионе без пиринга и подключаться к классической виртуальной сети. Эта функция ограничена планами Windows для службы приложений и не функционирует с виртуальными сетями, подключенными через ExpressRoute. Рекомендуется использовать интеграцию региональной виртуальной сети. Дополнительные сведения см. в разделе "Настройка интеграции виртуальной сети, необходимой для шлюза".

Среда службы приложений

Среда cлужбы приложений Azure (ASE) — это развертывание службы приложений Azure для одного клиента в виртуальной сети Azure. Ниже приведены несколько сценариев использования для этой функции.

• Доступ к ресурсам в виртуальной сети
• Доступ к ресурсам с использованием подключений ExpressRoute.
• Предоставьте доступ к вашим приложениям с частным адресом в вашей виртуальной сети.
• Доступ к ресурсам через конечные точки служб.
• Доступ к ресурсам через частные конечные точки.

При использовании Среды службы приложений вам не нужно использовать интеграцию виртуальной сети, поскольку Среда службы приложений уже находится в вашей виртуальной сети. Для получения доступа к таким ресурсам, как SQL или Azure Storage, через конечные точки службы, включите их в подсети ASE. Если вы хотите получить доступ к ресурсам в виртуальной сети или частным конечным точкам в виртуальной сети, вам не нужно выполнять дополнительные настройки. Например, вам нужно обеспечить доступ к ресурсам с помощью подключения ExpressRoute. При этом вам не нужно ничего настраивать в ASE или приложениях, так как вы уже находитесь в виртуальной сети.

Поскольку приложения в среде ILB ASE могут быть доступны по частному IP-адресу, вы можете добавить устройства WAF, чтобы выставить только некоторые приложения в интернет. Отсутствие разглашения информации о других помогает обеспечить безопасность остальных. Эта функция помогает упростить разработку многоуровневых приложений.

В настоящее время некоторые из этих возможностей не поддерживаются из многоклиентской службы, но доступны из Среды службы приложений Azure. Далее приводятся некоторые примеры.

• Размещение приложений в одной службе клиента.
• Масштабируйтесь до большего числа инстанций, чем это возможно в многопользовательской среде.
• Загрузка частных сертификатов клиента ЦС для использования приложениями с закрытыми конечными точками, защищенными центром сертификации.
• Принудительное использование протокола TLS 1.2 для всех приложений, размещенных в системе, без возможности отключения на уровне приложения.

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

• ASE выполняется в виртуальной сети, но она имеет зависимости за пределами виртуальной сети. Эти зависимости должны быть разрешены. См. статью Рекомендации по работе с сетями в среде Службы приложений.
• В отличие от многоклиентских служб, ASE не поддерживает мгновенное масштабирование. Необходимо прогнозировать потребность в масштабировании, а не реагировать на уже возникшую.
• ASE имеет более высокую первоначальную стоимость. Чтобы максимально эффективно использовать ASE, следует планировать размещение многочисленных рабочих нагрузок в одном ASE, а не использовать его для мелких задач.
• Приложения в ASE не могут выборочно ограничивать доступ к некоторым из них, но не к другим.
• ASE находится в подсети. Все правила сети применяются ко всему входящему и исходящему трафику этого ASE. Чтобы назначить правила входящего трафика только для одного приложения, используйте ограничения доступа.

Объединение функций

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

Размещение приложения в виртуальной сети

Как разместить приложение в виртуальной сети? Если приложение размещено в виртуальной сети, входящие и исходящие конечные точки приложения находятся в пределах этой сети. ASE — лучший способ решения этой проблемы. Тем не менее объединение функции позволяет удовлетворить большую часть потребностей многоклиентской службы. Например, можно размещать приложения только для интрасети с частными адресами для входящих и исходящих вызовов. Для этого используйте следующие возможности.

• Создание шлюза приложений с частными адресами для входящих и исходящих вызовов.
• Защита входящего трафика приложения с помощью конечных точек службы.
• Использование функции интеграции виртуальной сети для размещения серверной части приложения в виртуальной сети.

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

Создание многоуровневых приложений

Многоуровневое приложение — это приложение, в котором доступ к серверным приложениям API предоставляется только из внешнего уровня. Существует два способа создания многоуровневого приложения. Начните с использования интеграции виртуальной сети, чтобы подключить внешнее веб-приложение к подсети в виртуальной сети. Это позволяет веб-приложению выполнять вызовы в виртуальную сеть. После подключения внешнего приложения к виртуальной сети решите, как заблокировать доступ к приложению API. Вы можете:

• Разместить внешний интерфейс и приложение API в одном ILB ASE и предоставить доступ к внешнему приложению через Интернет с помощью шлюза приложений.
• Разместить внешний интерфейс в многоклиентской службе, а серверную часть — в ILB ASE.
• Разместить внешний интерфейс и приложение API в многоклиентской службе.

Если вы размещаете внешний интерфейс и приложение API для многоуровневого приложения, вы можете сделать следующее:

• Предоставить доступ к приложению API с помощью частных конечных точек в виртуальной сети:

  

• Используйте конечные точки службы, чтобы обеспечить, что входящий трафик к вашему API приложению поступает только из подсети, используемой вашим фронт-енд веб-приложением.

  

Ниже приведены некоторые рекомендации, которые помогут выбрать метод использования.

• При использовании конечных точек службы необходимо защитить только трафик, поступающий к приложению API в подсети интеграции. Конечные точки службы помогают защитить API-приложение, но может произойти утечка данных из вашего фронтенд-приложения в другие приложения в сервисе приложений.
• При использовании частных конечных точек у вас есть две подсети, что повышает сложность структуры. Кроме того, частная конечная точка является ресурсом верхнего уровня, что ведет к увеличению затрат на управление. Преимущество использования частных конечных точек заключается в исключении утечки данных.

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

Бизнес-приложения

Линейные бизнес-приложения (LOB) — это внутренние приложения, которые обычно недоступны через интернет. Эти приложения вызываются из корпоративных сетей, доступ к которым строго контролируется. Использование ILB ASE позволяет с легкостью размещать бизнес-приложения. При использовании многоклиентской службы можно использовать частные конечные точки или конечные точки службы совместно со шлюзом приложений. Существует два сценария, в которых следует использовать шлюз приложений с конечными точками службы вместо частных конечных точек.

• Необходимо обеспечить защиту на ваших бизнес-приложениях с помощью межсетевого экрана веб-приложений.
• Вы хотите распределить нагрузку между несколькими экземплярами ваших линейных бизнес-приложений.

Если ни одно из этих требований не актуально, следует использовать частные конечные точки. Если в Службе приложений Azure доступны частные конечные точки, вы можете использовать частные адреса для размещения приложений в виртуальной сети. Доступ к частной конечной точке, размещенной в виртуальной сети, можно предоставить через подключения ExpressRoute и VPN.

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

Порты Службы приложений

Если вы сканируете службу приложений, то обнаружите несколько портов, открытых для входящих подключений. В многоклиентской службе нельзя заблокировать эти порты или контролировать доступ к ним. Ниже приведен список доступных портов.