Ограничения на доступ к Службам приложений Azure

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

Принцип работы

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

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

Вы можете настроить набор правил ограничения доступа для каждого сайта. Правила ограничения доступа оцениваются в порядке приоритета. Если некоторые правила имеют одинаковый приоритет, они оцениваются в том порядке, в каком порядке они отображаются при возврате из API Azure Resource Manager и в портал Azure перед сортировкой. Вы также можете определить поведение, если правила не совпадают. В следующих разделах приведены подробные сведения.

Доступ к приложению

Доступ к приложению позволяет настроить доступ, если доступ доступен через конечную точку по умолчанию (общедоступная). Это поведение настраивается как для того Disabled , так и Enabled. Если доступ включен, вы можете добавить правила ограничения доступа к сайту для управления доступом из выбора виртуальных сетей и IP-адресов.

Если параметр не задан (свойство nullимеет значение), поведение по умолчанию — включить доступ, если частная конечная точка не существует, что изменяет поведение для отключения доступа. В портал Azure, если свойство не задано, переключатель также не задан, и вы используете поведение по умолчанию.

В API Azure Resource Manager вызывается publicNetworkAccessсвойство, управляющее доступом к приложению. Для внутренней подсистемы балансировки нагрузки (ILB) Среда службы приложений точка входа по умолчанию для приложений всегда является внутренней в виртуальной сети. Включение доступа к приложениям (publicNetworkAccess) не предоставляет прямой общедоступный доступ к приложениям. Вместо этого он разрешает доступ из точки входа по умолчанию, которая соответствует внутреннему IP-адресу Среда службы приложений. Если вы отключите доступ к приложению на Среда службы приложений ILB, вы можете получить доступ только к приложениям через частные конечные точки, добавленные в отдельные приложения.

Доступ к сайту

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

Для ограничения доступа к сайту есть несколько типов правил, которые можно применить:

Несоответствующее правило

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

Правила ограничения доступа на основе IP-адресов

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

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

Сведения о том, как включить эту функцию, см. в разделе Настройка ограничений доступа.

Правила ограничения доступа на основе конечных точек службы

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

Дополнительные сведения о настройке конечных точек службы в приложении см. в статье Ограничения доступа для Службы приложений Azure.

Любой источник конечной точки службы

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

Правила ограничения доступа на основе тегов службы

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

Полный список тегов и дополнительные сведения см. по ссылке тега службы.

Сведения о том, как включить эту функцию, см. в разделе Настройка ограничений доступа.

Правила с несколькими источниками

В одном правиле с несколькими источниками можно объединить до восьми диапазонов IP-адресов или восьми тегов служб. Если у вас более 512 ДИАПАЗОНов IP-адресов, можно использовать правила с несколькими источниками. Можно также использовать правила с несколькими источниками, если вы хотите создать логические правила, в которых несколько диапазонов IP-адресов объединяются с одним фильтром заголовков HTTP.

Правила с несколькими источниками определяются так же, как правила с одним источником при этом диапазоны в них разделяются запятыми.

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

Фильтрация заголовков HTTP для правил ограничения доступа к сайтам

Для любого правила, независимо от типа, можно добавить фильтрацию заголовков HTTP. Это обеспечивает дополнительную проверку входящих запросов и фильтрацию на основе определенных значений заголовков HTTP. Каждый заголовок может иметь до восьми значений для каждого правила. Ниже перечислены поддерживаемые заголовки HTTP:

• X-Forwarded-For. Стандартный заголовок для идентификации исходного IP-адреса клиента, подключающегося через прокси-сервер. Принимает допустимые IP-адреса.
• X-Forwarded-Host. Стандартный заголовок для идентификации исходного узла, запрошенного клиентом. Принимает любую строку длиной до 64 символов.
• X-Azure-FDID. Пользовательский заголовок для идентификации экземпляра обратного прокси-сервера. Azure Front Door отправляет guid, определяющий экземпляр, но его также можно использовать для прокси-серверов, отличных от Майкрософт, для идентификации конкретного экземпляра. Принимает любую строку длиной до 64 символов.
• X-FD-HealthProbe. Пользовательский заголовок для идентификации пробы работоспособности обратного прокси-сервера. Azure Front Door отправляет "1", чтобы однозначно определить запрос пробы работоспособности. Заголовок также можно использовать для прокси-серверов, отличных от Майкрософт, для идентификации проб работоспособности. Принимает любую строку длиной до 64 символов.

Ниже рассмотрены некоторые варианты использования фильтрации заголовков HTTP.

• Ограничение доступа к трафику с прокси-серверов, пересылающих имя узла.
• Ограничение доступа к определенному экземпляру Azure Front Door с помощью правила тега службы и ограничения заголовка X-Azure-FDID.

Ведение журнала диагностики

Служба приложений может отправлять различные категории ведения журнала в Azure Monitor. Одна из этих категорий вызывается IPSecurity Audit logs и представляет действия в ограничениях доступа. Все запросы, соответствующие правилу (за исключением несоответветного правила), разрешают и запрещают, регистрируются и могут использоваться для проверки конфигурации ограничений доступа. Возможность ведения журнала также является мощным инструментом при устранении неполадок в настройке правил.

Расширенные варианты использования

Сочетание вышеперечисленных функций позволяет решить некоторые варианты использования, которые описаны в следующих разделах.

Блокировка одного IP-адреса

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

Ограничение доступа к сайту с дополнительными инструментами

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

Развертывание через частную конечную точку

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

Разрешение доступа внешних партнеров к защищенному сайту частной конечной точки

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

Ограничение доступа к определенному экземпляру Azure Front Door

Трафик из Azure Front Door в приложение поступает из известного набора диапазонов IP-адресов, определенных в теге AzureFrontDoor.Backend службы. С помощью правила ограничения для тега службы можно ограничить трафик, только тем, который исходит от Azure Front Door. Чтобы убедиться, что трафик поступает только из конкретного экземпляра, необходимо дополнительно отфильтровать входящие запросы на основе уникального заголовка HTTP, который Azure Front Door отправляет под названием X-Azure-ПИИD. Идентификатор Front Door можно найти на портале.

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