Поделиться через


Рекомендации по архитектуре для Шлюза приложений Azure версии 2

Шлюз приложений Azure версии 2 — это подсистема балансировки нагрузки веб-трафика, которая работает на уровне приложения. Шлюз приложений управляет трафиком веб-приложений на основе атрибутов HTTP-запроса. Используйте шлюз приложений для сценариев с расширенными возможностями маршрутизации и требуют повышенной безопасности и масштабируемости.

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

Это важно

Как использовать это руководство

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

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

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

Область технологии

В этом обзоре рассматриваются взаимосвязанные решения для следующих ресурсов Azure:

  • Шлюз приложений версии 2
  • Брандмауэр веб-приложения (WAF) в шлюзе приложений

Надежность

Цель компонента "Надежность" заключается в обеспечении непрерывной функциональности путем создания достаточной устойчивости и возможности быстрого восстановления после сбоев.

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

Контрольный список проектирования

Начните стратегию проектирования на основе контрольного списка для проверки надежности. Определите её значимость для ваших бизнес-требований, принимая во внимание функции Application Gateway и его зависимости. Расширьте стратегию, чтобы включить дополнительные подходы по мере необходимости.

  • Используйте шлюз приложений версии 2 в новых развертываниях, если для рабочей нагрузки не требуется шлюз приложений версии 1.

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

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

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

  • Оцените влияние параметров интервала и порогового значения на пробу работоспособности. Проба работоспособности отправляет запросы в настроенную конечную точку с заданным интервалом. И серверная часть допускает ограниченное количество неудачных запросов, прежде чем она помечается как неисправная. Эти параметры могут конфликтуть, что представляет компромисс.

    • Более высокий интервал ставит более высокую нагрузку на службу. Каждый экземпляр шлюза приложений отправляет собственную пробу работоспособности, поэтому 100 экземпляров каждые 30 секунд равны 100 запросам каждые 30 секунд.

    • Более низкий интервал увеличивает время, прежде чем проба работоспособности обнаруживает сбой.

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

    • Высокий порог увеличивает количество времени, необходимого для вывода серверной части из ротации.

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

    Если каждый вызов к конечной точке здоровья совершает прямой вызов зависимостей, то эта база данных обрабатывает 100 запросов каждые 30 секунд вместо одного запроса. Чтобы избежать множества запросов, точка проверки состояния должна кэшировать данные о зависимостях на короткое время.

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

  • Учтите ограничения портов преобразования сетевых адресов источника (SNAT) в вашем дизайне , которые могут повлиять на внутренние подключения в Application Gateway. Некоторые факторы влияют на то, как шлюз приложений достигает предела порта SNAT. Например, если серверная часть является общедоступным IP-адресом, требуется собственный порт SNAT. Чтобы избежать ограничений портов SNAT, можно выполнить один из следующих вариантов:

    • Увеличьте количество экземпляров для каждого шлюза приложений.

    • Масштабируйте бэкенды, чтобы иметь больше IP-адресов.

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

      Если шлюз приложений Application Gateway достигает лимита портов SNAT, это влияет на запросы в секунду (RPS). Например, шлюз приложений не может открыть новое подключение к серверной части, и запрос завершается сбоем.

Рекомендации

Рекомендация Преимущества
Развертывание экземпляров Шлюза приложений в конфигурации с учетом зон.

Проверьте региональную поддержку избыточности зон, так как не все регионы предлагают эту функцию.
При распределении нескольких экземпляров между зонами рабочая нагрузка сможет выдержать сбои в одной зоне. Если зона недоступна, трафик автоматически перенаправляется на исправные экземпляры в других зонах, что поддерживает надежность приложений.
Используйте пробы работоспособности шлюза приложений для обнаружения недоступности серверной части. Пробы работоспособности обеспечивают, что трафик направляется только на серверные компоненты, которые могут обрабатывать трафик. Шлюз приложений отслеживает работоспособность всех серверов в серверном пуле и автоматически останавливает отправку трафика на любой сервер, который он считает неработоспособным.
Настройте правила ограничения скорости для Azure WAF, чтобы клиенты не могли отправлять слишком большой трафик в приложение. Используйте ограничение скорости, чтобы избежать таких проблем, как повторные штормы.
Не используйте UDR'ов на шлюзе приложений, чтобы внутренний отчет о работоспособности функционировал правильно и создавал правильные журналы и метрики.

Если необходимо использовать UDR в подсети шлюза приложений, см. раздел поддерживаемых определяемых пользователем маршрутов.
Определяемые пользователем объекты в подсети шлюза приложений могут вызвать некоторые проблемы. Не используйте определяемые пользователем маршруты в подсети шлюза приложений, чтобы просмотреть состояние серверной части, журналы и метрики.
Настройте параметры IdleTimeout в соответствии с характеристиками прослушивателя и трафика серверного приложения. Значение по умолчанию — четыре минуты. Можно настроить его максимум на 30 минут.

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

Безопасность

Цель компонента "Безопасность" — обеспечить конфиденциальности, целостности и доступности гарантии рабочей нагрузки.

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

Контрольный список проектирования

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

  • Просмотрите базовые показатели безопасности шлюза приложений.

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

    Узнайте, как WAF влияет на изменение емкости шлюза приложений. При включении WAF, шлюз приложений работает следующим образом:

    • Буферизирует каждый запрос до тех пор, пока он не будет полностью доставлен.

    • Проверяет, совпадает ли запрос с любым нарушением правила в основном наборе правил.

    • Перенаправляет пакет в серверные экземпляры.

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

    При использовании Azure Front Door и Шлюза приложений для защиты приложений HTTP или HTTPS используйте политики WAF в Azure Front Door и заблокируйте шлюз приложений для получения трафика только из Azure Front Door. Некоторые сценарии могут вынудить вас реализовать правила на шлюзе приложений. Например, если требуется правила ModSec CRS 2.2.9, CRS 3.0 или CRS 3.1, эти правила можно реализовать только в шлюзе приложений. И наоборот, Azure Front Door поддерживает ограничение скорости и геофильтрация, а шлюз приложений не поддерживает эти функции.

  • Разрешить только авторизованный доступ к плоскости управления. Используйте управление доступом на основе ролей (RBAC) шлюза приложений, чтобы ограничить доступ только для тех идентификаторов, которым это необходимо.

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

    Используйте известный ЦС для выдачи сертификата TLS серверного сервера. Если для выдачи сертификата не используется доверенный ЦС, шлюз приложений проверяет, пока не будет найден доверенный сертификат ЦС. Он устанавливает безопасное подключение только при обнаружении доверенного ЦС. В противном случае шлюз приложений помечает серверную часть как неработоспособную.

  • Защита секретов приложений. Используйте Azure Key Vault для хранения сертификатов TLS для повышения безопасности и упрощения процесса продления и смены сертификатов.

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

    Используйте соответствующий сервер системы доменных имен (DNS) для ресурсов внутреннего пула. Если внутренний пул содержит полностью разрешаемое полное доменное имя (FQDN), разрешение DNS основано на частной зоне DNS или пользовательском DNS-сервере (если настроено в виртуальной сети), или использует DNS, предоставленный по умолчанию Azure.

  • Отслеживайте аномальное действие. Регулярно просматривайте журналы, чтобы проверять наличие атак и ложных срабатываний. Отправьте журналы WAF из Шлюза приложений в централизованную систему управления информацией о безопасности и событиями (SIEM) вашей организации, такую как Microsoft Sentinel, чтобы обнаруживать шаблоны угроз и интегрировать профилактические меры в проектирование рабочей нагрузки.

Рекомендации

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

Шлюз может получить доступ к содержимому запроса и принимать интеллектуальные решения по маршрутизации.

Необходимо установить сертификат только в Шлюзе приложений, что упрощает управление сертификатами.
Интеграция шлюза приложений с Key Vault для хранения сертификатов TLS. Такой подход обеспечивает более надежную безопасность, упрощенное разделение ролей и обязанностей, поддержку управляемых сертификатов и более простой процесс продления и смены сертификатов.
Соблюдайте все ограничения NSG для шлюза приложений. Подсеть шлюза приложений поддерживает группы безопасности сети, но существуют некоторые ограничения. Например, некоторая коммуникация с определенными диапазонами портов запрещена. Убедитесь, что вы понимаете последствия этих ограничений.

Оптимизация затрат

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

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

Контрольный список проектирования

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

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

  • Удалите неиспользуемые экземпляры Шлюза приложений и оптимизируйте неиспользуемые экземпляры. Чтобы избежать ненужных затрат, определите и удалите экземпляры Шлюза приложений, имеющие пустые серверные пулы. Остановите экземпляры шлюза приложений, если они не используются.

  • Оптимизируйте затраты на масштабирование экземпляра Шлюза приложений. Чтобы оптимизировать стратегию масштабирования и уменьшить требования wokload, ознакомьтесь с рекомендациями по оптимизации затрат на масштабирование.

    Чтобы масштабировать службу в зависимости от требований к трафику приложения, используйте автомасштабирование в Шлюзе приложений версии 2.

  • Отслеживайте метрики потребления шлюза приложений и понять их влияние на затраты. Azure взимает плату за помесячно оплачиваемые экземпляры Шлюза приложений на основе отслеживаемых метрик. Оцените различные метрики и единицы емкости и определите драйверы затрат. Дополнительные сведения см. в разделе "Управление затратами Майкрософт".

Рекомендации

Рекомендация Преимущества
Остановите экземпляры шлюза приложений, если они не используются. Дополнительные сведения см. в разделе Stop-AzApplicationGateway и Start-AzApplicationGateway. Остановленный экземпляр шлюза приложений не несет затрат. Экземпляры шлюза приложений, которые постоянно работают, могут вызвать ненужные затраты. Оцените шаблоны использования и остановите экземпляры, когда они не нужны. Например, ожидается низкая активность после рабочих часов в средах разработки и тестирования.
Отслеживайте ключевые факторы затрат, такие как метрики шлюза приложений, например:

Оценка выставленных единиц емкости.
— фиксированные единицы емкости с выставлением счетов.
— Текущие единицы емкости.

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

Операционное превосходство

Операционное превосходство в первую очередь сосредоточено на процедурах практиках разработки, наблюдаемости и управления выпусками.

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

Контрольный список проектирования

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

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

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

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

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

Рекомендации

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

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

— Число неработоспособных хостов
— Состояние ответа, например ошибки 4xx и 5xx
— состояние ответа сервера, например ошибки 4xx и 5xx
время отклика бэкэнда на последний байт
— общее время шлюза приложений

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

Шлюз приложений проверяет наличие обновленной версии сертификата в связанном экземпляре Key Vault каждые 4 часа. Если версия сертификата недоступна из-за неправильной конфигурации Key Vault, она регистрирует ошибку и отправляет соответствующую рекомендацию помощника.

Эффективность производительности

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

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

Контрольный список проектирования

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

    Шлюз приложений версии 2 масштабируется на основе многих аспектов, таких как ЦП, пропускная способность сети и текущие подключения. Чтобы определить приблизительное число экземпляров, следует учитывать следующие метрики:

    • Текущие единицы вычислений: Эта метрика указывает на использование ЦП. Один экземпляр шлюза приложений равен примерно 10 единиц вычислений.

    • Производительность: Экземпляр шлюза приложений может обслуживать примерно 500 Мбит/с пропускной способности. Эти данные зависят от типа полезной нагрузки.

    Учитывайте это уравнение при вычислении количества экземпляров. Уравнение, показывающее приблизительное число экземпляров.

    После оценки количества экземпляров сравните это значение с максимальным числом экземпляров. Используйте это сравнение, чтобы узнать, насколько вы приближаетесь к максимально доступной емкости.

  • Воспользуйтесь преимуществами функций автомасштабирования и повышения производительности. SKU версии 2 предлагает автомасштабирование, которое увеличивает масштаб шлюза приложений по мере увеличения трафика. По сравнению с SKU v1, SKU v2 обладает возможностями, повышающими производительность рабочей нагрузки. Например, SKU v2 имеет лучшую производительность разгрузки TLS, более быстрое развертывание, обновление и поддержку отказоустойчивости зон. Дополнительные сведения см. в разделе Масштабирование шлюза приложений версии 2 и WAF v2.

    Если вы используете шлюз приложений версии 1, рассмотрите возможность миграции на шлюз приложений версии 2. Дополнительные сведения см. в разделе "Миграция шлюза приложений" и WAF из версии 1 в версию 2.

Рекомендации

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

Проверьте текущие единицы вычислений за прошлый месяц. Эта метрика представляет использование ЦП шлюза. Чтобы определить минимальное число экземпляров, разделите пиковое использование на 10. Например, если среднее число текущих вычислительных единиц в прошлом месяце равно 50, задайте для минимального числа экземпляров значение 5.
Для шлюза приложений версии 2 автоматическое масштабирование занимает около трех–пяти минут, прежде чем дополнительный набор экземпляров будет готов к работе с трафиком. В течение этого времени, если шлюз приложений имеет короткие пики трафика, ожидается временная задержка или потеря трафика.
Задайте максимально допустимое число экземпляров автомасштабирования , что составляет 125 экземпляров. Убедитесь, что выделенная подсеть шлюза приложений имеет достаточно доступных IP-адресов для поддержки увеличенного набора экземпляров.

Если ваши потребности в трафике превышают 125 экземпляров, вы можете использовать Azure Traffic Manager или Azure Front Door перед шлюзом приложений. Для получения более подробной информации см. Подключите Azure Front Door Premium к шлюзу приложений Azure через Private Link и Используйте шлюз приложений Azure с диспетчером трафика Azure.
Шлюз приложений может масштабироваться по мере необходимости для обработки повышенного трафика в приложениях. Этот параметр не увеличивает затраты, так как вы оплачиваете только потребляемую емкость.
Корректно определить размер выделенной подсети шлюза приложений. Настоятельно рекомендуется использовать подсеть /24 для развертывания шлюза приложений версии 2.

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

Дополнительные сведения об изменении размера подсети см. в разделе "Конфигурация инфраструктуры шлюза приложений".
Используйте подсеть /24, чтобы обеспечить поддержку всех IP-адресов, необходимых для развертывания шлюза приложений версии 2.

Шлюз приложений использует один частный IP-адрес для каждого экземпляра и другой частный IP-адрес, если вы настроите частный внешний IP-адрес. SKU Standard_v2 или WAF_v2 поддерживает до 125 экземпляров.

Azure резервирует пять IP-адресов в каждой подсети для внутреннего использования.

Политики Azure

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

  • Необходимо включить WAF для шлюза приложений. Разверните WAF перед общедоступными веб-приложениями, чтобы добавить другой уровень проверки для входящего трафика. WAF обеспечивает централизованную защиту для веб-приложений. Это помогает предотвратить распространенные эксплойты и уязвимости, такие как внедрение SQL, межсайтовые скрипты и локальные и удаленные выполнения файлов. Вы также можете использовать настраиваемые правила для ограничения доступа к веб-приложениям на основе стран или регионов, диапазонов IP-адресов и других параметров HTTP или HTTPS.

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

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

Для комплексного управления ознакомьтесь со встроенными определениями политики Azure и другими политиками , которые могут повлиять на сеть.

Рекомендации Помощника по Azure

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

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