Сеть для рабочих нагрузок SaaS в Azure

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

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

Решения SaaS имеют уникальные требования к сети. При подключении большего числа клиентов и их использования требования к сети изменяются. Обработка роста может быть сложной из-за ограниченных ресурсов, таких как диапазоны IP-адресов. Ваша сетевая конструкция влияет на безопасность и изоляцию клиентов. Спланируйте стратегию сети для управления ростом, повышением безопасности и снижением операционной сложности.

Рекомендации по проектированию

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

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

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

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

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

  • Общие сведения о топологиях сети. Топологии сети обычно делятся на три категории:

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

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

    • Нет сети: используйте топологию без сети для платформы Azure как услуга (PaaS), где можно размещать сложные рабочие нагрузки без развертывания виртуальных сетей. Например, служба приложение Azure обеспечивает прямую интеграцию с другими службами PaaS через магистральную сеть Azure. Хотя этот подход упрощает управление, он ограничивает гибкость при развертывании элементов управления безопасностью и возможности оптимизации производительности. Такой подход хорошо подходит для облачных приложений. По мере развития решения ожидается переход на топологию концентратора и периферийной с течением времени.

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

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

Рекомендации по проектированию

Рекомендация Преимущества
Определите, какие сетевые компоненты являются общими и какие компоненты выделены клиенту.

Совместное использование ресурсов, которые взимается за экземпляр, например Брандмауэр Azure, Бастион Azure и Azure Front Door.		 Балансируйте поддержку между требованиями к безопасности и изоляции, уменьшая затраты и операционные нагрузки.
Начните с плоской топологии или без сети.

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

Проектирование периметра сети с высокой безопасностью

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

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

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

Внимание

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

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

Дополнительные сведения см. в рекомендациях SE:06 по сети и подключению.

Рекомендации по проектированию

  • Защита трафика входящего трафика и управление ими. Проверьте этот трафик для входящих угроз.

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

    Веб-приложения уязвимы для распространенных атак, таких как внедрение SQL, межсайтовые скрипты и другие уязвимости OWASP. Функция брандмауэра веб-приложения Azure помогает защитить от этих атак и интегрироваться с Шлюзом приложений Azure и Azure Front Door. Просмотрите уровни этих служб, чтобы понять, какие возможности WAF находятся в каких продуктах.

    Распределенные атаки типа "отказ в обслуживании" (DDoS) представляют собой риск для приложений, подключенных к Интернету. Azure предоставляет базовый уровень защиты без затрат. Защита от атак DDoS Azure обеспечивает расширенную защиту путем обучения шаблонов трафика и корректировки защиты соответствующим образом, но эти функции поступают за счет затрат. Если вы используете Azure Front Door, воспользуйтесь встроенными возможностями DDoS.

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

    Рекомендуется использовать обратную прокси-службу, например Azure Front Door для глобального управления трафиком HTTP и HTTPS. Кроме того, используйте Шлюз приложений или другие службы Azure для управления входящего трафика. Дополнительные сведения см. в разделе "Параметры балансировки нагрузки".

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

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

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

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

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

Рекомендации по проектированию

Рекомендация Преимущества
Храните каталог сетевых конечных точек, предоставляемых Интернету. Захватить такие сведения, как IP-адрес (если он статический), имя узла, порты, протоколы, используемые конечными точками, и обоснование подключений.

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

Например, вам нужно больше механизмов управления для того, чтобы предоставлять клиентам доступ к конечным точкам учетной записи хранения. Эти элементы управления включают подписанные URL-адреса доступа, файрволы аккаунтов хранилищ и отдельные учетные записи хранения для внутреннего и внешнего использования.		 Вы можете выбрать элементы управления, соответствующие вашим потребностям в безопасности, затратах и производительности.
Для приложений на основе HTTP и HTTPS используйте обратный прокси-сервер, например Azure Front Door или шлюз приложений. Обратные прокси-серверы предоставляют широкий спектр возможностей для улучшения производительности, устойчивости и безопасности. Они также помогают снизить операционную сложность.
Проверьте входящий трафик с помощью WAF.

Избегайте выставления веб-ресурсов, таких как Служба приложений или Служба Azure Kubernetes (AKS) непосредственно в интернет.		 Вы можете более эффективно защитить веб-приложения от распространенных угроз и уменьшить общий уровень воздействия решения.
Защита приложения от атак DDoS.

Используйте Azure Front Door или защиту от атак DDoS в зависимости от протоколов, используемых общедоступными конечными точками.		 Защита решения от распространенных атак.
Если приложению требуется подключение исходящего трафика в масштабе, используйте шлюз NAT или брандмауэр для предоставления дополнительных портов SNAT. Вы можете поддерживать более высокий уровень масштабирования.

Возможность подключения нескольких сетей

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

Рекомендации по проектированию

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

    Расположение ресурса Ответственный Варианты подключения для рассмотрения
    Azure Клиент
    • Частная конечная точка (в клиентах Microsoft Entra)
    • Пиринг между виртуальными сетями (в клиентах Microsoft Entra)
    • Конечная точка службы (в клиентах Microsoft Entra)
    Другой поставщик облачных служб IsV или customer
    • VPN типа "сеть-сеть"
    • Azure ExpressRoute
    • Интернет
    Локально IsV или customer
    • VPN типа "сеть-сеть"
    • ExpressRoute
    • Интернет

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

      Компромисс: безопасность и стоимость. Приватный канал помогает убедиться, что трафик остается в частной сети. Мы рекомендуем использовать Private Link для сетевого подключения между тенантами Microsoft Entra. Однако каждая частная конечная точка несет затраты, которые могут сложиться в зависимости от ваших потребностей в безопасности. Конечные точки службы могут быть экономичной альтернативой. Они сохраняют трафик в магистральной сети Майкрософт, обеспечивая уровень частного подключения.

    • Конечные точки службы направляют трафик к ресурсам PaaS через магистральную сеть Майкрософт, которая защищает обмен данными между службами. Конечные точки службы могут быть экономически эффективными для приложений с высокой пропускной способностью, но необходимо настроить и поддерживать списки управления доступом для обеспечения безопасности. Поддержка конечных точек службы в клиентах Microsoft Entra зависит от службы Azure. Проверьте документацию по продукту для каждой используемой службы.

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

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

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

  • План на основе назначения. Возможно, вам потребуется подключиться к ресурсам в разных клиентах Microsoft Entra, особенно если целевой ресурс находится в подписке Клиента Azure. Рассмотрите возможность использования частных конечных точек, VPN типа "сеть — сеть" или одноранговых виртуальных сетей. Дополнительные сведения см. в статье «Создание пиринга виртуальной сети между разными подписками».

    Чтобы подключиться к ресурсам, которые хостит другой поставщик облачных услуг, обычно используется общедоступное подключение к Интернету, VPN типа "сеть — сеть" или ExpressRoute. Дополнительные сведения см. в статье Подключение к другим поставщикам облачных служб.

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

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

  • Общие сведения о выставлении счетов за исходящий трафик сети. Как правило, Azure взимает счета за исходящий сетевой трафик при выходе из сети Майкрософт или перемещении между регионами Azure. При разработке решений с несколькими регионами или несколькими облаками важно понимать последствия затрат. Варианты архитектуры, такие как использование Azure Front Door или ExpressRoute, могут повлиять на то, как вы оплачиваете сетевой трафик.

Рекомендации по проектированию

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

Только рассмотрите возможность маршрутизации через Интернет после оценки связанных последствий безопасности и производительности.		 Частный трафик проходит защищенный сетевой путь, который помогает снизить многие типы рисков безопасности.
При подключении к ресурсам, размещенным в средах Azure клиентов, используйте приватный канал, конечные точки службы или пиринги виртуальной сети. Вы можете сохранить трафик в сети Майкрософт, что помогает сократить затраты и операционную сложность по сравнению с другими подходами.
При подключении между поставщиками облачных услуг или к локальным сетям используйте VPN соединения типа "сеть-сеть" или ExpressRoute. Эти технологии обеспечивают безопасные подключения между поставщиками.

Разверните в средах ваших клиентов

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

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

Рекомендации по проектированию

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

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

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

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

Рекомендации по проектированию

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

Дополнительные ресурсы

Мультитенантность — это основная бизнес-методология разработки рабочих нагрузок SaaS. В этих статьях содержатся дополнительные сведения, связанные с проектированием сети:

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

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

Область разработки: данные для рабочих нагрузок SaaS в Azure

  • Last updated on