Изменение архитектуры целевой зоны Azure для удовлетворения требований в нескольких расположениях

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

Например, может быть два конфликтующих нормативных акта, регулирование A и регулирование B. Регламент A может требовать размещение данных в стране или регионе А, а регулирование B может потребовать расположения данных в стране или регионе B.

К таким нормативным конфликтам могут применяться следующие конфликты:

• Многонациональные организации, такие как многонациональные корпорации или неправительственные организации (НПО), которые должны соответствовать местным нормативным актам в странах или регионах, в которых они работают.

• Независимые поставщики программного обеспечения (ISV), предоставляющие решения организациям в нескольких расположениях, и решение должно соответствовать местным правилам в каждом расположении.

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

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

Рекомендации по регулированию

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

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

Если применяются несколько правил, вам не нужно изменять архитектуру целевой зоны Azure, если:

• Для нескольких правил требуются одинаковые Политика Azure назначения.

• Элементы управления в одном регулировании являются супермножеством другого регулирования. Элементы управления надмножества автоматически применяются к обоим нормативным требованиям.

• Элементы управления в нескольких правилах не перекрываются. При реализации нескольких наборов элементов управления одна реализация охватывает все нормативные акты. Политика Azure назначения являются дополнительными.

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

Совет

Вы должны стремиться иметь как можно меньше назначений политик и исключений или исключений.

Рекомендации по независимым поставщикам программного обеспечения

Существует три модели развертывания для поставщиков программного обеспечения.

• Чистое программное обеспечение как услуга (SaaS): isV предоставляет решение в качестве службы.

• Клиент развернут: клиент развертывает решение в собственной среде.

• SaaS с двумя развертываниями: эта модель объединяет развернутую клиентом модель и чистую модель SaaS.

В чистой модели SaaS isV отвечает за управление соответствием от имени клиента. IsV должен продемонстрировать соответствие клиенту и потенциально аудиторам или регуляторам. Если вы используете модель SaaS, архитектура может быть подвержена нескольким правилам, которые могут конфликтовать. IsV должен управлять соответствием для этих различных нормативных требований. Дополнительные сведения см . в разделе в этой статье: сценарии, требующие изменения.

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

Совет

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

В модели SaaS с двумя развертываниями применяются все рекомендации по развертыванию, развернутой клиентом и чистой модели SaaS.

Рекомендации по многонациональным организациям

Многонациональные организации используют различные структуры для организации управления ИТ-ресурсами.

• Децентрализованная структура: ИТ-функции управляются локально в каждом географическом расположении.

• Централизованная структура: ИТ-функции управляются из централизованного места, как правило, штаб-квартиры организации.

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

В децентрализованном сценарии локальная ИТ-группа отвечает за управление соответствием и может соответствующим образом адаптировать целевую зону.

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

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

Сценарии, требующие изменения

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

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

Клиенты Microsoft Entra

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

• Если необходимо отделить корпоративный клиент Microsoft Entra от клиента SaaS Microsoft Entra, чтобы повысить безопасность и создать четкие границы между продуктом и бизнес-операциями.

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

При совместной работе между несколькими клиентами Microsoft Entra необходимо тщательно планировать значительные проблемы и потребности. Создайте только минимальное количество клиентов Microsoft Entra, необходимых для удовлетворения операционных или нормативных требований. Группы управления и управление доступом на основе ролей Azure (RBAC) можно использовать для управления доступом к подпискам и ресурсам в одном клиенте, как описано в следующем разделе.

Совет

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

На следующих схемах показаны параметры, которые можно использовать для упорядочивания клиентов Microsoft Entra.

Совет

Если у вас несколько клиентов Microsoft Entra для соблюдения нормативных требований, присвойте клиентам имя на основе географического расположения, а не конкретных правил, например contoso-ops-us.com на схеме примера.

Дополнительные сведения см. в целевых зонах Azure и нескольких клиентах Microsoft Entra и рекомендациях по isV для целевых зон Azure.

Группы управления

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

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

Примечание.

На этой схеме не отображаются все группы управления.

Общий доступ к группе управления платформой

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

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

Изоляция удостоверений и безопасности

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

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

Изоляция подключения

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

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

Если правила конфликтуют с подключением, а также удостоверениями и безопасностью, можно использовать следующую структуру.

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

• Целевые зоны Azure и несколько клиентов Microsoft Entra
• Рекомендации по isV для целевых зон Azure
• Microsoft Cloud Adoption Framework для Azure
• Идентификатор и место расположения данных Microsoft Entra
• Обзор принципа безопасности
• Рекомендации для управления удостоверениями и доступом
• Настройка архитектуры целевой зоны Azure в соответствии с требованиями