Реализация сети нулевого доверия для веб-приложений с помощью брандмауэра Azure и шлюза приложений Azure

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

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

Как правило, различные типы сетевых устройств проверяют различные аспекты сетевых пакетов:

  • Брандмауэры веб-приложений ищут шаблоны, указывающие на атаку на уровне веб-приложения.

  • Брандмауэры следующего поколения также могут искать универсальные угрозы.

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

Архитектура

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

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

Эта архитектура использует протокол TLS для шифрования трафика на каждом шаге.

  1. Клиент отправляет пакеты в Шлюз приложений. Он выполняется с необязательным добавлением брандмауэра веб-приложения Azure.

  2. Шлюз приложений завершает TLS. Если Брандмауэр веб-приложений Azure включен, он проверяет запрос на угрозы веб-приложения. Затем шлюз приложений устанавливает новый сеанс TLS и перенаправляет разрешенные запросы в соответствии с настроенными правилами маршрутизации.

  3. Брандмауэр Azure Premium выполняет следующие проверки безопасности:

  4. Если пакеты проходят эти проверки, Брандмауэр Azure Premium выполняет следующие действия:

    • Он шифрует пакеты.
    • Она использует службу доменных имен (DNS) для определения виртуальной машины приложения.
    • Он перенаправит пакеты на виртуальную машину приложения.

Различные подсистемы проверки в этой архитектуре обеспечивают целостность трафика:

  • Брандмауэр веб-приложений Azure использует правила для предотвращения атак на веб-уровне. Примеры атак включают внедрение кода SQL и межсайтовые скрипты. Дополнительные сведения о правилах и Открытом проекте по безопасности веб-приложений (OWASP) в Основном наборе правил (CRS) см. в разделе группы правил CRS и правила для брандмауэра веб-приложения.

  • Брандмауэр Azure Premium использует универсальные правила обнаружения и предотвращения вторжений. Эти правила помогают выявлять вредоносные файлы и другие угрозы, предназначенные для веб-приложений.

Эта архитектура поддерживает следующие типы сетевой структуры, которые рассматриваются в этой статье:

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

Брандмауэр Azure 'Премиум' и разрешение имен

Когда брандмауэр Azure Premium проверяет вредоносный трафик, он проверяет, соответствует ли заголовок узла HTTP IP-адресу пакета и порту протокола TCP. Например, предположим, что шлюз приложений отправляет веб-пакеты в IP-адрес 172.16.1.4 и TCP-порт 443. Значение заголовка хоста HTTP должно указывать на этот IP-адрес.

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

Замечание

Шлюз приложений не поддерживает номера портов в заголовках узла HTTP. В результате:

  • Брандмауэр Azure Premium предполагает, что TCP-порт HTTPS по умолчанию имеет значение 443.
  • Подключение между шлюзом приложений и веб-сервером поддерживает только TCP-порт 443, а не нестандартные порты.

Цифровые сертификаты

На следующей схеме показаны общие имена (CN) и центры сертификации (ЦС), которые используются в сеансах TLS и сертификатах этой архитектуры.

Схема, показывающая CN и CA, которые использует сеть веб-приложения, когда балансировщик нагрузки находится перед брандмауэром.

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

ПОДКЛЮЧЕНИЯ TLS

Эта архитектура содержит три отдельных подключения TLS. Цифровые сертификаты проверяют каждый из них.

От клиентов к шлюзу приложений

В шлюзе приложений вы развертываете цифровой сертификат, который видят клиенты. Хорошо известный ЦС, например DigiCert или Let's Encrypt, обычно выдает такой сертификат. Этот механизм принципиально отличается от того, как брандмауэр Azure динамически генерирует цифровые сертификаты с использованием самоподписанного или внутреннего ЦС инфраструктуры открытых ключей.

Из шлюза приложений в брандмауэр Azure Premium

Для расшифровки и проверки трафика TLS Брандмауэр Azure Premium динамически создает сертификаты. Брандмауэр Azure Premium также выступает в роли веб-сервера для шлюза приложений. Промежуточный сертификат ЦС, настроенный для Брандмауэр Azure Premium, подписывает сертификаты, создаваемые Брандмауэр Azure Premium. Дополнительные сведения см. в сертификаты брандмауэра Azure Premium. Шлюз приложений должен проверить эти сертификаты. В параметрах серверной части шлюза приложений (иногда называемых параметрами HTTP) загрузите соответствующий корневой сертификат ЦС (.cer) как доверенный корневой сертификат.

С брандмауэра Azure Premium на веб-сервер

Брандмауэр Azure Premium устанавливает сеанс TLS с целевым веб-сервером. Брандмауэр Azure Premium проверяет, что известный УЦ подписывает пакеты TLS веб-сервера.

Роли компонентов

Шлюз приложений и Брандмауэр Azure Premium обрабатывают сертификаты по-разному, так как их роли отличаются:

  • Шлюз приложений — это обратный веб-прокси-сервер. Он защищает веб-серверы от вредоносных клиентов путем перехвата HTTP-запросов и HTTPS. Вы объявляете каждый защищенный сервер, который находится в серверном пуле шлюза приложений с его IP-адресом или полным доменным именем. Допустимые клиенты должны иметь доступ к каждому приложению. Вы настраиваете шлюз приложений с цифровым сертификатом, подписанным публичным ЦС. Используйте ЦС, который принимает любой клиент TLS.

  • Брандмауэр Azure Premium — это прямой веб-прокси-сервер. То есть он действует как веб-прокси, защищая клиентов от вредоносных веб-серверов путем перехвата TLS-запросов от защищенных клиентов. Когда защищенный клиент выполняет HTTP-запрос, веб-прокси, действующий от имени целевого веб-сервера, создает цифровые сертификаты и предоставляет их клиенту. Брандмауэр Azure Premium использует частный ЦС, который подписывает динамически созданные сертификаты. Вы настраиваете защищенные клиенты, чтобы они доверяли частному ЦУС. В этой архитектуре Брандмауэр Azure Premium защищает запросы от шлюза приложений к веб-серверу. Шлюз приложений доверяет частному сертификатному центру, который использует Брандмауэр Azure Premium.

Маршрутизация и пересылка трафика

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

  • Шлюз приложений всегда выступает в качестве прокси-сервера. В этой архитектуре Брандмауэр Azure Premium также служит прокси-сервером, так как проверка TLS включена в правиле приложения. Шлюз приложений завершает сеансы TLS от клиентов и создает новые сеансы TLS для Брандмауэр Azure. Брандмауэр Azure завершает эти сеансы и создает новые сеансы TLS для рабочих нагрузок. Если трафик соответствует сетевому правилу, Брандмауэр Azure перенаправит его без проверки TLS правила приложения. То, применяет ли Брандмауэр Azure политики IDPS, зависит от конфигурации IDPS. Дополнительные сведения см. в разделе IDPS и частные IP-адреса.

  • Для трафика, обрабатываемого правилом приложений, рабочая нагрузка видит подключения, поступающие с IP-адреса подсети Брандмауэр Azure, поскольку правила приложений принуждают брандмауэр работать как прокси-сервер; в результате конечный узел назначения видит пакет как отправленный с IP-адресов брандмауэра. Хотя проксирование — не то же самое, что трансляция адресов, для упрощения можно представить это поведение с помощью мысленной модели, в которой правила приложений всегда используют трансляцию исходного сетевого адреса (SNAT). Исходный IP-адрес клиента сохраняется в заголовке X-Forwarded-For HTTP, который вставляет шлюз приложений. Брандмауэр Azure также поддерживает внедрение исходного IP-адреса клиента в заголовке X-Forwarded-For. В этом сценарии IP-адрес исходного клиента — ЭТО IP-адрес шлюза приложений.

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

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

Топология «звезда-лучи»

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

  • Устранение неполадок с оповещениями брандмауэра веб-приложений Azure может быть сложной задачей. Как правило, вам нужны подробные знания о приложении, чтобы решить, являются ли сообщения, которые вызывают эти оповещения законными.

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

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

В традиционных центральных и периферийных архитектурах частные зоны DNS обеспечивают простой способ использования DNS:

  1. Настройка частной зоны DNS.
  2. Свяжите зону с виртуальной сетью, содержащей брандмауэр Azure Premium.
  3. Убедитесь, что запись адреса существует для значения, которое шлюз приложений использует для трафика и для проверок работоспособности.

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

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

  1. Клиент отправляет запрос на веб-сервер.

  2. Шлюз приложений перехватывает клиентские пакеты и проверяет их. Если пакеты проходят проверку, шлюз приложений отправляет пакеты к серверной виртуальной машине. UDR в подсети шлюза приложений задает Брандмауэр Azure Premium в качестве следующего прыжка, поэтому пакеты переходят к Брандмауэр Azure Premium, прежде чем они достигают виртуальной машины приложения.

  3. Брандмауэр Azure Premium выполняет проверки безопасности пакетов. Если они успешно проходят проверку, Брандмауэр Azure Premium перенаправляет пакеты на виртуальную машину приложения по новому TLS-подключению.

  4. Виртуальная машина реагирует непосредственно на брандмауэр, так как Брандмауэр Azure использует правила приложения, поэтому виртуальная машина видит только IP-адреса Брандмауэр Azure в качестве источников.

  5. Брандмауэр Azure Premium знает из внутренних таблиц, что это подключение поступило из шлюза приложений и перенаправит трафик соответствующим образом.

  6. Шлюз приложений отвечает клиенту.

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

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

  1. Локальный клиент подключается к шлюзу виртуальной сети.

  2. Шлюз виртуальной сети перенаправит клиентские пакеты в шлюз приложений.

  3. Шлюз приложений проверяет пакеты. Если они проходят проверку, UDR в подсети шлюза приложений пересылает пакеты в Брандмауэр Azure Premium.

  4. Брандмауэр Azure Premium выполняет проверки безопасности пакетов. Если они проходят проверки, Брандмауэр Azure Premium перенаправляет пакеты на виртуальную машину приложения по новому TLS-подключению.

  5. Виртуальная машина реагирует непосредственно на брандмауэр, так как Брандмауэр Azure использует правила приложения, поэтому виртуальная машина видит только IP-адреса Брандмауэр Azure в качестве источников.

  6. Брандмауэр Azure Premium знает из внутренних таблиц, что это подключение поступило из шлюза приложений и перенаправит трафик соответствующим образом.

  7. Шлюз приложений отправляет пакеты клиенту, используя шлюз виртуальной сети в качестве следующего узла.

  8. Шлюз виртуальной сети перенаправит пакеты клиенту.

Топология виртуальной глобальной сети

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

При использовании Виртуальная глобальная сеть в качестве сетевой платформы следует учитывать два основных различия:

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

    Чтобы реализовать разрешение DNS для брандмауэра Azure Premium, используйте DNS-серверы.

  • Вы можете использовать только Виртуальная глобальная сеть для настройки маршрутов в подключенном сегменте, если префикс короче (менее конкретный), чем префикс виртуальной сети. Например, на предыдущих схемах в спицевой виртуальной сети есть префикс 172.16.0.0/16. В этом случае виртуальная глобальная сеть не может внедрить маршрут, соответствующий префиксу виртуальной сети (172.16.0.0/16) или любой из подсетей (172.16.0.0/24, 172.16.1.0/24). Другими словами, виртуальная глобальная сеть не может направлять трафик между двумя подсетями, которые находятся в одной виртуальной сети.

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

На следующей схеме показан поток пакетов в архитектуре, использующая виртуальную глобальную сеть. В этом сценарии доступ к Шлюзу приложений поступает из локальной сети. VPN типа "сеть — сеть" или шлюз ExpressRoute соединяет эту сеть с Виртуальная глобальная сеть. Следующий поток пакетов описывает трафик через VPN-шлюз, но поток через шлюз ExpressRoute будет идентичным. Доступ через Интернет следует аналогичному пути.

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

  1. Локальный клиент подключается к VPN-шлюзу виртуального концентратора.

  2. VPN-шлюз перенаправит клиентские пакеты в шлюз приложений.

  3. Шлюз приложений проверяет пакеты. Если они проходят проверку, подсеть шлюза приложений перенаправит пакеты в брандмауэр Azure Premium.

  4. Брандмауэр Azure Premium запрашивает разрешение DNS с DNS-сервера в виртуальной сети общих служб.

  5. DNS-сервер отвечает на запрос разрешения.

  6. Брандмауэр Azure Premium выполняет проверки безопасности пакетов. Если они проходят проверки, Брандмауэр Azure Premium передаёт пакеты на виртуальную машину приложения по новому TLS-подключению.

  7. Виртуальная машина реагирует непосредственно на брандмауэр, так как Брандмауэр Azure использует правила приложения, поэтому виртуальная машина видит только IP-адреса Брандмауэр Azure в качестве источников.

  8. Брандмауэр Azure Premium знает из внутренних таблиц, что это подключение поступило из шлюза приложений и перенаправит трафик соответствующим образом.

  9. Шлюз приложений отправляет пакеты клиенту, используя VPN-шлюз виртуального концентратора в качестве следующего перехода.

  10. VPN-шлюз виртуального концентратора перенаправит пакеты клиенту.

Раньше необходимо было изменить маршрутизацию, которую концентратор объявлял для периферийных виртуальных сетей, поскольку шлюз приложений версии 2 поддерживал только маршрут 0.0.0.0/0 с типом следующего перехода Internet. Однако это ограничение было исправлено с развертыванием частного шлюза приложений. На момент написания этой статьи необходимо вручную подключить подписку Azure к этой функции. Если вы подготовили шлюз приложений перед включением этой функции, необходимо убедиться, что маршрут по умолчанию не распространяется на подсеть шлюза приложений с помощью любого из этих методов:

  • Создайте таблицу маршрутов с маршрутом для 0.0.0.0/0 и типа следующего прыжка Internet. Свяжите этот маршрут с подсетью, в которую развертывается шлюз приложений.

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

NVAs и сервер маршрутизации

В этой топологии можно использовать виртуальные сетевые устройства (NVA), которые выполняют терминацию и проверку TLS-соединений. При необходимости можно использовать Route Server, чтобы автоматически добавлять маршруты в спицы. Используйте эту функцию, чтобы избежать административных расходов на обслуживание таблиц маршрутов. Сервер маршрутизации объединяет варианты виртуальной глобальной сети и концентратора и периферийных серверов:

  • Сервер маршрутизации можно использовать для управления виртуальными сетями концентратора. В результате вы можете связать виртуальную сеть концентратора с частной зоной DNS.

  • Сервер маршрутов имеет то же ограничение, что и Виртуальная WAN в отношении префиксов IP-адресов. Можно внедрить маршруты в спицевую сеть только в том случае, если префикс короче (менее специфичный), чем префикс виртуальной сети. Из-за этого ограничения шлюз приложений и целевой веб-сервер должны находиться в разных виртуальных сетях.

На следующей схеме показан поток пакетов, когда сервер маршрутизации упрощает динамическую маршрутизацию. Рассмотрим следующие моменты:

  • Для сервера маршрутизации в настоящее время требуется устройство, которое внедряет маршруты для отправки по протоколу BGP. Брандмауэр Azure Premium не поддерживает BGP, поэтому эта топология применима только для сторонних NVAs.

  • Функциональность NVA в хабе определяет, требуется ли использование DNS.

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

  1. Локальный клиент подключается к шлюзу виртуальной сети.

  2. Шлюз виртуальной сети перенаправит клиентские пакеты в шлюз приложений.

  3. Шлюз приложений проверяет пакеты. Если они проходят проверку, подсеть шлюза приложений перенаправит пакеты на внутренний компьютер. Сервер маршрутизации добавляет маршрут в подсеть шлюза приложений, которая перенаправляет трафик в сетевое виртуальное устройство (NVA).

  4. Подсеть NVA запрашивает разрешение DNS с DNS-сервера в виртуальной сети общих служб.

  5. DNS-сервер отвечает на запрос разрешения.

  6. NVA выполняет проверки безопасности пакетов. Если они успешно проходят проверки, NVA перенаправляет пакеты на виртуальную машину приложения по новому TLS-соединению.

  7. Виртуальная машина реагирует непосредственно на NVA, так как NVA ведет себя как прокси-сервер и запускает новое подключение TLS. Следовательно, виртуальная машина приложения видит только IP-адреса NVA в качестве источников.

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

  9. Шлюз приложений отправляет пакеты клиенту, используя шлюз виртуальной сети в качестве следующего узла.

  10. Шлюз виртуальной сети перенаправит пакеты клиенту.

Как и в случае с Виртуальная глобальная сеть, при использовании сервера маршрутизации может потребоваться изменить маршрутизацию, если только шлюз приложений не был подготовлен после включения функции развертывания частного шлюза приложений. Если вы объявляете маршрут 0.0.0.0/0 из NVA в Azure Route Server, по умолчанию он распространяется на подсеть Application Gateway. Если шлюз приложений не поддерживает частные развертывания, он не поддерживает этот маршрут. В этом случае настройте таблицу маршрутов для подсети шлюза приложений Application Gateway и добавьте в эту таблицу маршрут для 0.0.0.0/0 со следующим типом прыжка: Internet.

Системы обнаружения и предотвращения вторжений (IDPS) и частные IP-адреса

Брандмауэр Azure Premium решает, какие правила idPS применяются на основе исходных и целевых IP-адресов пакетов. По умолчанию брандмауэр Azure обрабатывает частные IP-адреса в диапазонах RFC 1918 (10.0.0.0/8, 192.168.0.0/16и) и 172.16.0.0/12RFC 6598 (100.64.0.0/10) как внутренние. Таким образом, если вы развертываете шлюз приложений в подсети в одном из этих диапазонов, брандмауэр Azure Premium рассматривает трафик между шлюзом приложений и рабочей нагрузкой, которая будет внутренней. Таким образом, используются только подписи IDPS, которые будут применены к внутреннему трафику или к любому трафику. Подписи IDPS, помеченные для входящего или исходящего трафика, не применяются к трафику между шлюзом приложений и рабочей нагрузкой. Дополнительные сведения см. в правилах IDPS для брандмауэра Azure.

Самый простой способ принудительного применения правил входящих сигнатур IDPS к трафику между шлюзом приложений и рабочей средой — размещение шлюза приложений в подсети, использующей префикс за пределами частных диапазонов. Для этой подсети не обязательно нужно использовать общедоступные IP-адреса. Вместо этого можно настроить IP-адреса, которые брандмауэр Брандмауэр Azure Premium обрабатывает как внутренние для систем обнаружения и предотвращения вторжений (IDPS). Например, если ваша организация не использует 100.64.0.0/10 диапазон, этот диапазон можно исключить из списка внутренних префиксов для системы обнаружения и предотвращения вторжений (IDPS) и развернуть шлюз приложений в подсети, настроенной с IP-адресом 100.64.0.0/10. Дополнительные сведения см. в разделе Диапазоны частных IPDS брандмауэра Azure premium.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

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

Дальнейшие шаги

  • Last updated on