Модификация архитектуры внедренческой зоны Azure для удовлетворения требований в нескольких местах

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

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

К таким нормативным конфликтам могут относиться:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В развернутой клиентом модели клиент отвечает за управление соответствием. Для этой модели 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.

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

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

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

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

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

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

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

Изоляция идентификации и безопасности

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

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

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

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

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

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

Дальнейшие шаги

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