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

Архитектурные подходы к сети в мультитенантных решениях

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

Замечание

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

Основные рекомендации и требования

Службы инфраструктуры и платформы

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

Службы инфраструктуры

При использовании служб инфраструктуры, таких как виртуальные машины или служба Azure Kubernetes (AKS), рассмотрите и создайте виртуальные сети, которые лежат в основе подключения служб. Кроме того, рассмотрите другие уровни безопасности и изоляции, которые необходимо включить в проект. Избегайте использования исключительно элементов управления уровня сети.

Службы платформы

При использовании служб платформы Azure, таких как Служба приложений Azure, Azure Cosmos DB или База данных SQL Azure, архитектура определяет необходимые сетевые службы.

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

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

  • Требования к соответствию: Возможно, вам потребуется соответствовать определенному стандарту соответствия. Некоторые стандарты требуют настройки среды Azure определенными способами, например с помощью определенных сетевых элементов управления. Дополнительные сведения см. в разделе "Архитектурные подходы к управлению и соответствию требованиям" в мультитенантных решениях.

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

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

Убедитесь, что вы понимаете последствия использования частной сети.

Размер подсетей

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

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

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

Ознакомьтесь с руководством по сегментации подсети при планировании подсетей.

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

Рассмотрите необходимость доступа клиентов к службам через Интернет или через частные IP-адреса.

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

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

Доступ к конечным точкам арендаторов

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

Если необходимо отправить данные конечным точкам клиентов, рассмотрите следующие распространенные подходы:

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

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

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

Подходы и шаблоны, которые следует учитывать

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

Виртуальные сети для конкретного клиента с ip-адресами, выбранными поставщиком услуг

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

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

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

Виртуальные сети для конкретного клиента с выбранными клиентом IP-адресами

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

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

Топология концентратора и периферийной топологии

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

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

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

Подсказка

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

Статические IP-адреса

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

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

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

Агенты

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

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

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

Сервисы Майкрософт, предоставляющие агенты для подключения к сетям клиентов-арендаторов, включают следующие примеры:

Служба Приватного канала обеспечивает частное подключение из среды Azure клиента к вашему решению. Арендаторы также могут использовать службу Private Link с собственной виртуальной сетью для доступа к вашей службе из локальной среды. Azure безопасно направляет трафик в службу с помощью частных IP-адресов.

Дополнительные сведения см. в статье «Многотенантность и Private Link».

Доменные имена, поддомены и TLS

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

Шаблоны маршрутизации и разгрузки шлюза

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

  • Маршрутизация запросов на серверные части или метки развертывания для конкретного клиента
  • Обработка доменных имен и сертификатов TLS для конкретного клиента
  • Проверка запросов на угрозы безопасности с помощью брандмауэра веб-приложения (WAF)
  • Кэширование ответов для повышения производительности

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

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

Шаблон размещения статического содержимого

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

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

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

Антипаттерны, которых следует избегать

Сбой планирования подключения к виртуальной сети

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

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

Игнорирование ограничений

Azure применяет множество ограничений, влияющих на сетевые ресурсы. К этим ограничениям относятся ограничения ресурсов Azure и фундаментальные протоколы и ограничения платформы. Например, при создании высокомасштабного мультитенантного решения на службах платформ, таких как Служба приложений и Функции Azure, может потребоваться учитывать количество подключений протокола TCP и портов преобразования сетевых адресов источника (SNAT). При работе с виртуальными машинами и подсистемами балансировки нагрузки также необходимо учитывать ограничения для исходящих правил и портов SNAT.

Небольшие подсети

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

Неправильное сегментирование сети

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

Использование только элементов управления безопасностью на уровне сети

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

Перезапись заголовков узлов без тестирования

При использовании шаблона разгрузки шлюза можно перезаписать Host заголовок HTTP-запросов. Эта практика может упростить настройку серверной службы веб-приложений, выгрузив личный домен и управление TLS на шлюз.

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

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

Соавторы

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

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

  • Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure

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

  • Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure
  • Джошуа Уадделл | Старший инженер по работе с клиентами, FastTrack для Azure

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