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

Сеть для рабочих нагрузок 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, они должны реализовать различные сетевые элементы управления, включая брандмауэр, брандмауэр веб-приложения и группы безопасности сети, чтобы выполнить требования к безопасности. Даже если вам не нужно немедленно соблюдать эти факторы расширяемости при проектировании архитектуры.

Рекомендации SE:06 по сети и подключению

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Развертывание в средах, принадлежащих клиентам

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

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

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

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

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

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

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

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

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

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

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

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

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

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