Рекомендации независимых поставщиков программного обеспечения (ISV) для целевых зон Azure
Для многих организаций концептуальная архитектура целевых зон Azure представляет собой назначение пути внедрения облака. Целевые зоны описывают, как создать среду Azure с несколькими подписками. Каждая целевая зона учитывается для масштабирования, безопасности, управления, сети и удостоверений, а также на основе отзывов и уроков, извлеченных многими клиентами.
Совет
Это может быть полезно, чтобы думать о целевых зонах Azure как о планах города. Архитектура рабочих нагрузок, развернутых в целевой зоне, похожа на планы строительства в городе.
Вода города, газ, электричество и транспортные системы должны быть на месте, прежде чем здания можно будет построить. Аналогичным образом компоненты целевой зоны Azure, в том числе группы управления, политики, подписки и управление доступом на основе ролей (RBAC), все необходимо установить перед развертыванием рабочих нагрузок.
Как независимый поставщик программного обеспечения (ISV) создает и работает в Azure, вы должны ссылаться на следующие ресурсы при создании среды Azure:
- Целевые зоны Azure. Предоставляет рекомендации по всей среде Azure.
- Azure Well-Architected Framework: предоставляет рекомендации по архитектуре, применимые ко всем рабочим нагрузкам.
- Проектирование мультитенантных решений в Azure. Предоставляет конкретные рекомендации по архитектуре для мультитенантных решений в Azure.
Целевые зоны Azure помогают выбрать направление для всей среды Azure. Но в качестве поставщика программного обеспечения, поставщика SaaS или запуска конкретные потребности реализации могут отличаться от более стандартных сценариев клиента. Ниже приведены несколько различных примеров сценариев реализации.
- Вы создаете программное обеспечение, которое клиенты развертывают в своих собственных подписках.
- У вас есть собственный уровень управления и использование сценариев автоматизации или программного обеспечения для развертывания и настройки ресурсов Azure для решений SaaS.
- Вы являетесь небольшим isV или запуском и хотите начать с наименьшей возможной стоимости, и может не потребоваться изначально использовать такие службы, как Брандмауэр Azure и Защита от атак DDoS Azure.
- Вы являетесь большим isV SaaS и планируете разделить приложение SaaS по нескольким подпискам для масштабирования. Вы также хотите сгруппировать подписки, чтобы они соответствовали вашим средам разработки, тестирования, промежуточной и рабочей среды.
- Операционная модель вашей организации отделяет роли корпоративной ИТ-команды и группы продуктов SaaS. Корпоративная ИТ-группа вашей организации может управлять такими ресурсами, как Microsoft Office 365 и Microsoft Teams, и ваша группа продуктов SaaS может отвечать за создание и эксплуатацию продукта SaaS (включая ее центральные компоненты платформы и удостоверений).
Примечание.
Иногда поставщики программного обеспечения хотят начать только с одной подписки Azure, которая включает как аспекты общих служб платформы, так и фактические ресурсы рабочей нагрузки. Хотя это технически возможно, вы столкнетесь с проблемами позже, когда необходимо переместить ресурсы между подписками и найти, что не все типы ресурсов можно переместить. Просмотрите влияние отклонений проектирования, чтобы понять, какие отклонения возможны и их различные уровни риска.
Модели развертывания поставщика программного обеспечения
Решения isV часто вписываются в одну из трех моделей развертывания: чистые SaaS, развернутые клиентом или двойное развертывание SaaS. В этом разделе описаны различные аспекты каждой модели для целевых зон Azure.
Pure SaaS
В чистой модели SaaS программное обеспечение развертывается полностью только в подписках Azure. Конечные клиенты используют программное обеспечение без его развертывания в собственных подписках Azure. На следующей схеме пользователи используют чистое приложение SaaS, предоставляемое isV:
Примерами чистого программного обеспечения SaaS являются электронная почта как услуга, Kafka-as-service, cloud-data-warehouse-as-service и многие описания SaaS в Azure Marketplace.
Если вы небольшой isV SaaS, вам может не потребоваться использовать несколько подписок Azure для развертывания ресурсов сразу. Но при масштабировании ограничения подписки Azure могут повлиять на возможность масштабирования в пределах одной подписки. Ознакомьтесь с принципами проектирования целевой зоны масштаба предприятия, особенно демократизацией подписок, и ознакомьтесь с архитектурными подходами к мультитенантности для планирования будущего роста.
Поставщики программного обеспечения, создающие чистые решения SaaS, должны рассмотреть следующие вопросы:
- Должны ли все ресурсы Azure, составляющие наше решение SaaS, находиться в одной подписке Azure или секционироваться по нескольким подпискам Azure?
- Следует ли размещать каждого клиента в собственной выделенной подписке Azure или создавать ресурсы в одной или нескольких общих подписках?
- Как применить шаблон метки развертывания (единицы масштабирования) ко всем уровням нашего решения?
- Как мы можем использовать организацию ресурсов Azure в мультитенантных решениях , чтобы помочь нам столкнуться с масштабируемыми проблемами и ограничениями подписки Azure?
Развернутый клиентом
В развернутой клиентом модели конечные клиенты покупают программное обеспечение от вас, а затем развертывают его в собственных подписках Azure. Они могут инициировать развертывание из Azure Marketplace или сделать это вручную, выполнив инструкции и используя скрипты, которые вы предоставляете.
На следующей схеме поставщик программного обеспечения предоставляет пакет программного обеспечения или продукт каталога Azure Marketplace, а пользователи развертывают этот ресурс в собственных подписках Azure вместе с другими рабочими нагрузками:
Другой элемент рабочей нагрузки клиента на схеме может представлять собственную рабочую нагрузку клиента или другой продукт поставщика программного обеспечения, развернутый в подписке Azure. Клиенты часто развертывают несколько продуктов из разных поставщиков программного обеспечения в подписках Azure. Они объединяют эти отдельные продукты для создания решений. Например, клиент может развернуть продукт базы данных из одного поставщика программного обеспечения, сетевого виртуального устройства из другого поставщика программного обеспечения и веб-приложения из третьего поставщика программного обеспечения.
Примеры развернутых клиентом продуктов ISV включают множество образов виртуальных машин (таких как сетевые и виртуальные устройства хранилища) и приложения Azure в Azure Marketplace.
Для некоторых решений, развернутых клиентом, организация может предоставлять управление и обновления для решения, развернутого в подписках Azure конечного клиента с помощью Azure Lighthouse или управляемых приложений Azure. Поставщики программного обеспечения, интеграторы решений (SIs) и поставщики управляемых служб (MSPs) могут использовать эту стратегию, если она соответствует их конкретным потребностям.
Решения, развернутые клиентом, считаются стандартной рабочей нагрузкой приложений с точки зрения целевых зон Azure. Рассмотрим рекомендации по целевым зонам Azure при разработке продукта для работы с принципами проектирования целевых зон Azure, которые применяют клиенты Azure.
Особенно важно иметь хорошее представление о концепциях целевой зоны Azure при переносе рабочих нагрузок существующих клиентов в Azure.
Поставщики программного обеспечения, создающие решения, развернутые клиентом, должны учитывать следующие вопросы:
- Должен ли клиент развернуть наше решение в собственной выделенной подписке или в существующей подписке, содержащей связанные рабочие нагрузки?
- Как клиенты должны установить сетевое подключение между существующими рабочими нагрузками (внутри и за пределами Azure) и нашим решением?
- Поддерживает ли наше решение механизмы проверки подлинности из идентификатора Microsoft Entra или требуются ли другие протоколы, такие как LDAP или Kerberos?
- Как уменьшить или исключить нарушения Политика Azure, такие как конфликты между шаблонами решений и политиками Azure клиента?
Политики Azure клиента, которые могут привести к нарушениям Политика Azure, включают примеры, такие как "Все подсети должны иметь группу безопасности сети" и "Общедоступные IP-адреса не могут быть присоединены к сетевым интерфейсам в целевой зоне Corp". Имейте в виду потенциал этих политик, вызывающих конфликт, при планировании развертывания.
Двойное развертывание SaaS
Некоторые решения SaaS взаимодействуют с ресурсами, развернутыми в подписках Azure клиентов или используют их. Эта модель развертывания иногда называется гибридной моделью двойного развертывания SaaS или SaaS. На следующей схеме поставщик программного обеспечения предоставляет размещенное решение SaaS, которое взаимодействует с ресурсами, развернутыми в подписке Azure конечного клиента:
Реальный пример двойного развертывания SaaS — microsoft Power BI, служба SaaS, которая может использовать локальный шлюз данных Power BI, развернутый на виртуальной машине в подписке Azure клиента.
К другим примерам сценариев двойного развертывания SaaS относятся:
- Ваша организация создает Диспетчер виртуальных рабочих столов, продукт, предоставляющий консольный интерфейс SaaS для управления ресурсами Виртуального рабочего стола Azure в подписке Azure клиента.
- Ваша организация предоставляет консоль SaaS для аналитики данных и динамически создает и удаляет виртуальные машины вычислительного узла в подписке Azure каждого клиента.
В качестве поставщика программного обеспечения для двойного развертывания следует обратиться к целевой зоне Azure для указания в двух областях: структурирование собственной среды Azure для размещения службы SaaS и обеспечение правильного взаимодействия между развертываниями в подписках Azure клиентов и целевых зонах клиентов.
Поставщики программного обеспечения, создающие решения SaaS для двойного развертывания, должны учитывать следующие вопросы:
- Мы рассмотрели все рекомендации по созданию как чистых решений SaaS, так и развернутых клиентом?
- Какие компоненты нашего решения должны размещаться в наших подписках Azure и какие компоненты должны быть развернуты клиентом?
- Как обеспечить безопасную подготовку и взаимодействие с ресурсами, развернутыми в подписках Azure клиентов?
Принципы и реализации целевой зоны Azure
Принципы проектирования целевой зоны Azure рекомендуют соответствовать возможностям платформы Azure, таким как Log Analytics, Azure Monitor и Брандмауэр Azure. Руководство по целевой зоне также предоставляет конкретные варианты реализации целевой зоны Azure.
В качестве поставщика программного обеспечения вы можете решить реализовать собственные среды целевой зоны. Возможно, вам потребуется использовать собственную автоматизацию для развертывания ресурсов Azure в подписках. Или вы можете продолжить использовать средства, которые уже используются для ведения журнала, мониторинга и других служб уровня платформы.
Если вы реализуете собственные среды целевой зоны, рекомендуется использовать рекомендации по целевой зоне Azure и примеры реализаций для справки и выровнять подход с проверенными проектами целевой зоны Azure.
Клиенты Microsoft Entra
Каждая целевая зона Azure и ее иерархия групп управления коренится в одном клиенте Microsoft Entra. Это означает, что первое решение, которое необходимо принять, заключается в том, какой клиент Microsoft Entra будет использоваться в качестве источника удостоверений для управления ресурсами Azure. Удостоверения в идентификаторе Microsoft Entra включают пользователей, группы и субъекты-службы.
Совет
Клиент Microsoft Entra, выбранный для целевой зоны, не влияет на проверку подлинности на уровне приложения. Вы по-прежнему можете использовать другие поставщики удостоверений, такие как Azure AD B2C, независимо от выбранного клиента.
Руководство по целевым зонам Azure и клиентам Microsoft Entra настоятельно рекомендует использовать один клиент Microsoft Entra, и это правильный подход для большинства ситуаций. Однако в качестве поставщика программного обеспечения SaaS может потребоваться использовать два клиента.
Для некоторых независимых поставщиков программного обеспечения SaaS одна команда управляет корпоративными ресурсами, а отдельная команда управляет решением SaaS. Это разделение может быть по операционным причинам или соответствовать нормативным требованиям. Возможно, ваша корпоративная ИТ-команда не может управлять подписками и ресурсами, связанными с SaaS, поэтому они не могут быть администраторами клиента Microsoft Entra. Если этот сценарий применяется к вам, рассмотрите возможность использования двух отдельных клиентов Microsoft Entra: одного клиента для корпоративных ИТ-ресурсов, таких как Office 365, и одного клиента для ресурсов Azure, составляющих решение SaaS.
Каждый клиент Microsoft Entra должен иметь собственное доменное имя. Если в вашей организации используется два клиента, можно выбрать имя contoso.com для корпоративного клиента Microsoft Entra и contoso-saas-ops.com клиента SaaS Microsoft Entra, как показано на следующей схеме.
Предупреждение
При использовании нескольких клиентов Microsoft Entra увеличивается нагрузка на управление. Если вы используете функции Microsoft Entra ID P1 или P2, такие как управление привилегированными пользователями, необходимо приобрести отдельные лицензии для каждого клиента Microsoft Entra. Рекомендуется использовать только несколько клиентов Microsoft Entra, если вашей ситуации действительно требуется.
Избегайте использования отдельных клиентов Microsoft Entra для предварительной и рабочей сред. Вместо создания двух клиентов, таких как contoso-saas-ops-preprod.com и contoso-saas-ops-prod.com отдельных подписок Azure, следует создать один клиент Microsoft Entra. Группы управления и Azure RBAC можно использовать для управления доступом к подпискам и ресурсам в рамках этого отдельного клиента.
Дополнительные сведения об использовании нескольких клиентов Microsoft Entra см. в целевых зонах Azure и нескольких клиентах Microsoft Entra и изоляции ресурсов с несколькими клиентами.
Группы управления
Концептуальная архитектура целевой зоны Azure рекомендует использовать определенную иерархию групп управления. Однако поставщики программного обеспечения могут иметь разные требования, отличные от других организаций. В этом разделе описывается несколько способов, которыми может быть выбрана организация isV, чтобы применить различные методики, отличные от рекомендаций концептуальной архитектуры целевой зоны.
Группа управления верхнего уровня
Иерархия групп управления вложена в созданную Azure корневую группу управления клиентом. Вы не используете корневую группу клиента напрямую.
Стандартная организация, которая имеет централизованную корпоративную ИТ-группу, управляющую своей платформой и общими службами (например, ведение журнала, сеть, удостоверение и безопасность), обычно создает одну группу управления верхнего уровня в корневой группе клиента, созданной Azure, и развертывает остальные группы управления под ним. Эта группа управления верхнего уровня обычно называется самой организацией (например , Contoso).
В качестве поставщика программного обеспечения SaaS у вас может быть один продукт SaaS или у вас может быть несколько отдельных продуктов SaaS или бизнес-линий. Хотя вы обычно должны использовать тот же клиент Microsoft Entra для управления ресурсами Azure во всех продуктах (как описано в разделе клиентов Microsoft Entra), в некоторых сценариях можно развернуть несколько иерархий групп управления.
Рассмотрим, насколько независимы ваши продукты друг от друга, и спросите себя:
- Все ли наши продукты используют одни и те же платформы для DevOps, удостоверений, безопасности, подключения и ведения журнала?
- Работают ли эти общие службы одной центральной командой?
Если вы ответили на оба вопроса, создайте одну группу управления продуктами SaaS верхнего уровня в корневой группе клиента.
Если вы вместо этого ответили нет, и каждая из продуктов SaaS управляется отдельными группами платформ, рассмотрите возможность создания отдельной группы управления верхнего уровня для каждого продукта, например двух групп управления верхнего уровня SaaS Product-01 и SaaS Product-02.
Совет
Это редкость для одного поставщика программного обеспечения, чтобы иметь несколько нескольких групп управления верхнего уровня. Часто несколько продуктов можно объединить из-за сходства в том, как они управляются и работают.
Этот подход управления аналогичен подходу тестирования для целевых зон корпоративного масштаба. Однако вместо создания Contoso и Contoso-Canary в корневой группе клиента в этом подходе компания создаст группы управления верхнего уровня contoso-SaaS-Product-01, Contoso-SaaS-Product-02 и Contoso-SaaS-Product-03. Этот вариант сценария показан на схеме ниже.
Группа управления платформой
В иерархии организации ресурсов целевой зоны Azure группа управления платформой содержит все подписки Azure, в которых размещаются компоненты и общие службы, используемые рабочими нагрузками в подписках целевой зоны. Примеры компонентов, развернутых в подписках платформы и общих служб, включают централизованную инфраструктуру ведения журналов (например, рабочие области Log Analytics), DevOps, безопасность, средства автоматизации, центральные сетевые ресурсы (такие как планы централизованной сети и защиты от атак DDos), а также службы уровня управления isV.
Группа управления платформой часто секционируется в дочерние группы удостоверений, управления и подключения, чтобы обеспечить удобное разделение ролей и политик для корпоративных клиентов.
В организации может быть одна команда, которая управляет всеми компонентами общей платформы, такими как идентификация, сеть и управление. Если это так, и если у вас нет планов разделить это управление между несколькими командами, то рассмотрите возможность использования одной группы управления платформой .
Если вместо этого будут отдельные команды, которые управляют различными частями централизованной платформы, следует развернуть дополнительные уровни в иерархии групп управления в группе управления платформы. Это позволяет назначать отдельные политики для каждой части централизованной платформы.
На следующей схеме показаны две потенциальные реализации группы управления платформой . Вариант A показывает более комплексный сценарий, в котором группа управления платформой содержит три дочерние группы управления: Управление и DevOps, Identity and Security и Connectivity. Каждая дочерняя группа управления содержит подписку с соответствующими ресурсами. Вариант B показывает более простой сценарий, в котором группа управления платформой содержит одну подписку на платформу.
Группа управления целевыми зонами
Группа управления целевыми зонами содержит подписки Azure, в которых размещаются фактические подсистемы и рабочие нагрузки решения SaaS.
Эта группа управления содержит одну или несколько дочерних групп управления. Каждая из дочерних групп управления в целевых зонах представляет собой архетип рабочей нагрузки или подсистемы с согласованными требованиями к политике и доступу, которые должны применяться ко всем подпискам. Ниже перечислены причины использования нескольких архетипов:
- Соответствие требованиям. Если подсистема продукта SaaS должна быть совместима с PCI-DSS, рассмотрите возможность создания дочерней группы управления PCI DSS в целевых зонах. Все подписки Azure, содержащие ресурсы в области соответствия PCI-DSS, должны размещаться в этой группе управления.
- Уровни. Рассмотрите возможность создания отдельных архетипов целевой зоны для клиентов выделенного уровня SaaS и клиентов уровня "Бесплатный". Каждая из дочерних групп управления содержит разные параметры Политика Azure. Например, политики на уровне "Бесплатный" могут ограничивать развертывания только для включения определенных номеров SKU виртуальных машин, а политики в выделенном уровне могут потребовать развертывания ресурсов в определенных регионах.
Группы управления для конкретной среды
Поставщики программного обеспечения SaaS часто упорядочивают облачные среды путем моделирования сред жизненного цикла разработки программного обеспечения в последовательности. Обычно это требует развертывания в среде разработки, а затем в тестовой среде, а затем в промежуточной среде и, наконец, в рабочей среде.
Одним из распространенных различий между средами является их правила Azure RBAC, например доступ к каждой группе подписок. Например, команды Разработчиков, SaaSOps, разработки и тестирования могут иметь разные уровни доступа к разным средам.
Внимание
Большинство клиентов Azure имеют сотни приложений и используют отдельные подписки Azure для каждой команды приложений. Если у каждого приложения есть собственные группы разработки, тестирования, промежуточного хранения и рабочей среды, будет большое количество групп управления с практически идентичными политиками. Для большинства клиентов часто задаваемые вопросы о целевой зоне корпоративного масштаба советуют использовать отдельные группы управления для каждой среды. Вместо этого рекомендуется использовать отдельные подписки в одной группе управления.
Однако поставщики программного обеспечения SaaS могут иметь разные требования, отличные от большинства других клиентов Azure, и могут иметь хорошую причину использовать группы управления, относящиеся к среде, в некоторых ситуациях.
Поставщики программного обеспечения SaaS иногда должны группировать несколько подписок, представляющих сегменты или секции одной подсистемы, приложения или рабочей нагрузки. Возможно, потребуется применить политики или назначения ролей к группам подписок заметно иначе, чем в группе управления архетипами. В этом случае рекомендуется создавать дочерние группы управления, соответствующие каждой среде в группе управления архетипами.
На следующих схемах показаны два возможных варианта. Параметр A показывает сценарий с отдельными подписками для каждой среды, но без групп управления, зависящих от среды. Параметр B показывает сценарий SaaS ISV с группами управления, зависящими от среды, в группе управления регулярными метками . Каждая группа управления для конкретной среды содержит несколько подписок. Со временем isV масштабирует свои ресурсы Azure в каждой среде в разных подписках с общим набором политик и назначений ролей.
Выберите каждую вкладку, чтобы увидеть две схемы.
Отмена эксплуатации и групп управления песочницами
Руководство по организации ресурсов целевой зоны Azure рекомендует, включая группы управления "Песочницы" и "Изолированные" непосредственно под группой управления верхнего уровня.
Удаленная группа управления — это место хранения для подписок Azure, которые отключаются и в конечном итоге будут удалены. Вы можете переместить подписку, которая больше не используется в этой группе управления, чтобы отслеживать ее, пока все ресурсы в подписке не будут окончательно удалены.
Группа управления песочницами обычно содержит подписки Azure, которые используются для изучения и имеют свободные или не применяют к ним политики. Например, вы можете предоставить отдельным разработчикам собственные подписки для разработки и тестирования. Вы можете избежать применения обычных политик и управления к этим подпискам, разместив их в группе управления песочницами . Это повышает гибкость разработчиков и позволяет им легко экспериментировать с Azure.
Внимание
Подписки в группе управления песочницами не должны иметь прямого подключения к подпискам целевой зоны. Избегайте подключения подписок песочницы к рабочим нагрузкам или к любым непроизводственных средам, которые зеркально отражают рабочие среды.
На следующей схеме показаны два возможных варианта. Параметр A не включает группы управления песочницами и группами управления песочницами, в то время как вариант B выполняется.
Пример целевых зон ISV
В этом разделе представлено два примера структур целевой зоны Azure для поставщика программного обеспечения SaaS. Выберите каждую вкладку, чтобы сравнить два примера целевых зон.
На следующей схеме показан пример иерархии целевых зон SaaS ISV Azure со следующими характеристиками:
- IsV сохраняет все компоненты платформы в одной подписке Azure, а не разбивает их на несколько групп управления платформой.
- Существует только одна группа управления целевой зоной.
- Целевая зона включает группы управления для конкретной среды для организации подписок и назначения различных политик и ролей.
- IsV не включал группы управления для списанных и изолированных подписок.
Следующие шаги
- Если вы создаете мультитенантное решение, узнайте больше о разработке мультитенантных решений в Azure.
- Узнайте , что такое целевая зона Azure.
- Узнайте о областях проектирования целевой зоны Azure.