Использование конфигурации DNS с разделением мозга для размещения веб-приложения в Azure

Azure Front Door
Шлюз приложений Azure
Azure ExpressRoute
Azure DNS

Команды, которые управляют рабочими нагрузками, часто используют полностью квалифицированные доменные имена (FQDN) для доступа клиентов. Полные доменные имена (FQDN) обычно используются вместе с указанием имени сервера в Transport Layer Security (TLS), также известным как SNI. При таком подходе, когда общедоступные клиенты получают доступ к рабочей нагрузке из общедоступного Интернета или корпоративных клиентов к рабочей нагрузке внутри организации, маршрутизация к приложению может соответствовать фиксированным путям и иметь различные уровни безопасности или качества обслуживания (QoS).

В следующей архитектуре демонстрируется подход для различения способа обработки трафика на основе системы доменных имен (DNS) и того, исходит ли клиент из Интернета или из корпоративной сети.

Architecture

Схема архитектуры размещения приложений.

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

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

Общедоступный интернет-рабочий процесс

Схема общедоступного рабочего процесса Интернета.

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

  1. Клиенты отправляют запрос на app.contoso.com приложение через общедоступный Интернет.

  2. Зона Azure DNS настроена для домена contoso.com. Для конечных точек Azure Front Door настроены соответствующие канонические записи имени (CNAME).

  3. Внешние клиенты получают доступ к веб-приложению с помощью Azure Front Door уровня "Стандартный" или "Премиум", который работает как глобальная подсистема балансировки нагрузки и брандмауэр веб-приложения (WAF).

    • В Azure Front Door app.contoso.com назначается в качестве FQDN (полного доменного имени) через маршруты в настроенной конечной точке. Azure Front Door также размещает сертификаты SNI TLS для приложений.

      Note

      Azure Front Door не поддерживает самозаверяемые сертификаты.

    • Azure Front Door направляет запросы в настроенную группу источников на основе заголовка Host HTTP клиента.

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

  4. Группа безопасности сети (NSG) настроена в подсети AppGW, чтобы разрешить входящий доступ через порт 80 и порт 443 из тега службы AzureFrontDoor.Backend. Группа безопасности сети не разрешает входящий трафик через порт 80 и порт 443 из тега службы Интернета.

    Note

    Тег службы AzureFrontDoor.Backend не ограничивает трафик исключительно вашим экземпляром Azure Front Door. Проверка выполняется на следующем этапе.

  5. Экземпляр шлюза приложений имеет прослушиватель через порт 443. Трафик направляется в серверную часть на основе имени узла, указанного в прослушивателе.

    • Чтобы убедиться, что трафик поступает из профиля Azure Front Door, настройте настраиваемое правило WAF , чтобы проверить значение заголовка X-Azure-FDID .

    • Azure создает уникальный идентификатор для каждого профиля Azure Front Door. Уникальный идентификатор — это значение Azure Front Door ID, расположенное на странице обзора портала Azure.

  6. Трафик достигает вычислительного ресурса, настроенного как внутренний пул в шлюзе приложений.

Рабочий процесс частного предприятия

Схема рабочего процесса частного предприятия.

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

  1. Клиенты инициируют запрос приложения app.contoso.com из локальной среды.

  2. Полное доменное имя приложения настраивается на внутреннем DNS сервере. Этот поставщик DNS может быть локальным доменные службы Active Directory DNS-серверами (AD DS) или другими партнерскими решениями. Записи DNS для каждого полного доменного имени приложения настраиваются для указания частного IP-адреса экземпляра шлюза приложений.

  3. Канал Azure ExpressRoute или VPN типа "сеть — сеть" упрощает доступ к шлюзу приложений.

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

  5. Шлюз приложений имеет прослушиватель , настроенный на порт 80 и порт 443. Трафик направляется в серверную часть на основе имени узла, указанного в прослушивателе.

  6. Только частный сетевой трафик достигает вычислительных ресурсов, настроенных как внутренний пул в шлюзе приложений.

Components

  • DNS — это система, которая сопоставляет доменные имена с IP-адресами, что позволяет клиентам находить и подключаться к службам. Для общедоступного интернет-воркфлоу в этой архитектуре необходимо настроить общедоступную зону DNS с правильным CNAME для полного доменного имени конечной точки Azure Front Door. На стороне частной сети предприятия настройте локального поставщика DNS (AD DS DNS или партнерское решение), чтобы каждый FQDN приложения указывал на частный IP-адрес шлюза приложений.

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

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

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

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

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

Alternatives

В качестве альтернативного решения можно удалить Azure Front Door Standard или Premium и вместо этого указать общедоступную запись DNS на общедоступный IP-адрес Application Gateway. В соответствии с требованиями этой архитектуры необходимо кэшировать и оптимизировать трафик в точке входа в Azure. В результате вы не можете использовать альтернативное решение для этого сценария. Дополнительные сведения см. в разделе "Оптимизация затрат".

Схема альтернативной архитектуры размещения DNS с сплит-брейн.

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

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

  • Диспетчер трафика Azure: диспетчер трафика — это служба маршрутизации трафика на основе DNS, которая распределяет трафик между различными регионами и конечными точками. Traffic Manager можно использовать вместо Azure Front Door стандартного или премиум уровня для маршрутизации внешних клиентов к ближайшему экземпляру Application Gateway. Однако Azure Front Door предоставляет такие функции, как возможности WAF, кэширование и сходство сеансов. Диспетчер трафика не предоставляет эти функции.

  • Azure Load Balancer: Azure Load Balancer — это подсистема балансировки нагрузки сети, которая обеспечивает высокий уровень доступности и масштабируемость трафика протокола TCP и протокола пользовательской диаграммы данных (UDP). Вместо шлюза приложений можно использовать Load Balancer для маршрутизации внешних и внутренних запросов клиентов на внутренние веб-серверы. Однако шлюз приложений предоставляет такие функции, как возможности WAF, завершение SSL и привязка сеанса на основе файлов cookie. Load Balancer не предоставляет эти функции.

Сведения о сценарии

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

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

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

  • Защищает веб-приложение от распространенных веб-атак и вредоносного трафика.

Возможные варианты использования

Используйте эту архитектуру для сценариев, для которых требуется:

  • Split-brain DNS: Это решение использует Azure Front Door для внешних клиентов и шлюза приложений для внутренних клиентов с различными записями DNS для каждой службы. Этот подход помогает оптимизировать производительность сети, безопасность и доступность для различных клиентов.

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

Considerations

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

Reliability

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

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

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

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

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

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

Security

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектирования для обеспечения безопасности.

  • Используйте подход "Никому не доверяй". В настройке DNS с разделением мозга примените подход "Никому не доверяй". Четко проверьте идентичность клиента, независимо от того, подключен ли он через Интернет или корпоративную сеть. Этот подход гарантирует, что только доверенные сущности могут выполнять авторизованные действия.

  • Эффективно реализуйте элементы управления удостоверениями и доступом. Реализуйте Microsoft Entra ID для надежного управления удостоверениями. Используйте политики условного доступа Microsoft Entra для применения строгих элементов управления доступом на основе контекста клиента, работоспособности устройств и расположения.

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

      • Регулярно оцените свои оборонительные инвестиции. Регулярно оценивайте эффективность Azure Front Door и Application Gateway. Убедитесь, что они обеспечивают значимую защиту от угроз.

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

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

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

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

Другие улучшения безопасности

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

  • Брандмауэр Azure: Можно добавить Azure firewall в виртуальную сеть концентратора и использовать аналитику угроз Брандмауэр Azure, чтобы заблокировать вредоносный трафик от известных вредоносных IP-адресов и доменов. Брандмауэр Azure также можно использовать в качестве DNS-прокси для перехвата и проверки трафика DNS и применения правил фильтрации DNS.

  • Azure Front Door: Вы можете использовать Брандмауэр веб-приложений Azure для защиты веб-приложений от распространенных веб-уязвимостей и эксплойтов на границе. Вы также можете использовать приватный канал с уровнем Azure Front Door Premium для безопасного доступа к серверам внутренних приложений из Azure Front Door без предоставления доступа к общедоступному Интернету.

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

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

  • Внутренние вычисления: Многие факторы, такие как выбор номера SKU, количество реплик и регион, управляют затратами на выполнение внутренних вычислительных служб. Прежде чем выбрать оптимальный вариант для рабочей нагрузки, рассмотрите все элементы вычислительного ресурса .

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

  • Azure Front Door: Azure Front Door затраты зависят от количества правил маршрутизации, количества ЗАПРОСОВ HTTP или HTTPS и объема передаваемых данных. Вы можете использовать Azure Front Door standard или Premium для получения единого интерфейса с Azure Content Delivery Network, Брандмауэр веб-приложений Azure и Приватный канал. Вы также можете использовать функцию обработчика правил Azure Front Door для настройки управления трафиком и оптимизации производительности и затрат.

Если в вашем сценарии нет глобального доступа или дополнительных функций Azure Front Door, это решение можно использовать только с шлюзом приложений. Вы можете указать все общедоступные записи DNS на общедоступный IP-адрес, настроенный на слушателях шлюза приложений Application Gateway.

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

Contributors

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

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

Другие участники:

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

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