Проектирование мультитенантной архитектуры для крупных учреждений
Для небольших учреждений рекомендуется использовать архитектуру с одним клиентом. Однако для организаций с более чем 1 миллионом пользователей рекомендуется использовать мультитенантную архитектуру, чтобы устранить проблемы с производительностью и ограничения клиентов, такие как подписка и квоты Azure, а также Microsoft Entra ограничения и ограничения служб.
Принципы оформления
При проектировании мультитенантной архитектуры учитывайте следующие принципы проектирования, чтобы снизить затраты, повысить эффективность и безопасность.
Снижение затрат
Уменьшите зависимость от локальной инфраструктуры и нескольких поставщиков удостоверений.
Разрешить пользователям разблокировать свою учетную запись или сбросить пароли с помощью самообслуживания (например, Microsoft Entra самостоятельного сброса пароля).
Повышение эффективности
Стандартизация архитектуры, конфигураций и процессов между клиентами, чтобы свести к минимуму административные проблемы.
Сведите к минимуму потребность пользователей в переходе из одного клиента в другой
Повышение безопасности
Сосредоточьтесь на обеспечении безопасности данных учащихся.
Следуйте принципу минимальных привилегий: предоставьте только те привилегии, которые необходимы для выполнения необходимых задач, и реализуйте JIT-доступ.
Разрешить внешним пользователям доступ только через управление правами или Microsoft Entra совместной работы B2B.
Делегируйте администрирование определенных задач определенным пользователям с помощью just Enough Access (JEA) для выполнения этой задачи.
Распространенные причины для нескольких клиентов
Мы настоятельно рекомендуем организациям с менее чем 1 миллионом пользователей создавать один клиент, если другие критерии не указывают на необходимость в нескольких клиентах. Для организаций с 1 миллионом или более объектов пользователей рекомендуется использовать региональный подход для нескольких клиентов.
Создание отдельных клиентов влияет на среду EDU следующим образом.
Административное разделение
Может ограничить влияние административной безопасности или операционной ошибки, затрагивающей критически важные ресурсы.
Может ограничить влияние скомпрометированных учетных записей администраторов или пользователей.
Отчеты об использовании и журналы аудита содержатся в клиенте.
Разделение ресурсов
Конфиденциальность учащихся. Объекты учащегося пользователя можно обнаружить только в клиенте, в котором находится объект.
Изоляция ресурсов. Пользователи и администраторы других клиентов не могут обнаружить или перечислить ресурсы в отдельном клиенте.
Занимаемая объектами. Приложения, которые записывают данные в Microsoft Entra ID и другие службы Microsoft Online через Microsoft Graph или другие интерфейсы управления, могут влиять только на ресурсы в локальном клиенте.
Квоты. Потребление квот и ограничений Azure на уровне клиента отделяется от использования других клиентов.
Разделение конфигурации
Предоставляет отдельный набор параметров на уровне клиента, которые могут размещать ресурсы и доверенные приложения с различными требованиями к конфигурации.
Включает новый набор служб Microsoft Online, таких как Office 365.
Помимо более чем 1 миллиона пользователей, приведенные ниже рекомендации могут привести к нескольким клиентам.
Рекомендации по администра
Вы работаете в соответствии с правилами, ограничивающими тех, кто может управлять окружающей средой на основе таких критериев, как страна гражданства, страна проживания или уровень разрешения.
У вас есть требования к соответствию, такие как конфиденциальность данных учащихся, которые требуют создания удостоверений в определенных локальных регионах.
Рекомендации по ресурсам
У вас есть ресурсы, возможно, для исследований и разработок, которые необходимо защитить от обнаружения, перечисления или поглощения существующими администраторами по нормативным или критически важным причинам.
Цикл разработки пользовательских приложений, которые могут изменять данные пользователей с MS Graph или аналогичными API в большом масштабе (например, приложения, которым предоставлен каталог Directory.ReadWrite.All)
Рекомендации по настройке
- Ресурсы с требованиями, которые конфликтуют с существующими возможностями безопасности или совместной работы на уровне клиента, такими как разрешенные типы проверки подлинности, политики управления устройствами, возможность самообслуживания или проверка подлинности для внешних удостоверений.
Определение мультитенантного подхода
В этом разделе мы рассмотрим вымышленный университет под названием Школа изобразительных искусств с 2 миллионами студентов в 100 школах по всему США. В этих школах насчитывается в общей сложности 130 000 учителей и 30 000 штатных сотрудников и сотрудников.
При развертывании нескольких клиентов рекомендуется использовать региональный подход следующим образом:
Начните с разделения сообщества учащихся и преподавателей на географические регионы, где каждый регион содержит менее 1 миллиона пользователей.
Создайте клиент Microsoft Entra для каждого региона.
Подготовьте сотрудников, преподавателей и учащихся в соответствующем регионе для оптимизации взаимодействия.
Зачем использовать регионы?
Рекомендуется использовать региональный подход, чтобы свести к минимуму число пользователей, перемещающихся между клиентами. Если вы создали клиент для каждого учебного уровня (например, для начальных школ, средних школ и средних школ), вам придется переносить пользователей в конце каждого учебного года. Если вместо этого пользователи остаются в том же регионе, вам не придется перемещать их между арендаторами по мере изменения их атрибутов.
К другим преимуществам регионального подхода относятся:
Оптимальная совместная работа в каждом регионе
Требуется минимальное количество гостевых объектов из других клиентов
Если у клиента более 1 миллиона пользователей, возможности управления и средства со временем ухудшаются. Аналогичным образом, некоторые возможности конечных пользователей, такие как использование средства выбора людей, станут громоздкими и ненадежными.
Небольшие организации, которые решили развернуть несколько клиентов без веской причины, неоправданно увеличат затраты на управление и число миграций пользователей. Для этого также потребуются шаги для обеспечения совместной работы между клиентами.
Совместная работа между клиентами с помощью Microsoft Entra совместной работы B2B
Microsoft Entra совместной работы B2B позволяет пользователям использовать один набор учетных данных для входа в несколько клиентов. Для образовательных учреждений преимущества совместной работы B2B включают:
Команда централизованного администрирования, управляющая несколькими клиентами
Совместная работа преподавателей в разных регионах
Адаптация родителей и опекунов с их собственными учетными данными
Внешние партнерские отношения, такие как подрядчики или исследователи
При совместной работе B2B учетная запись пользователя, созданная в одном клиенте (его домашнем клиенте), приглашается в качестве гостевого пользователя в другой клиент (клиент ресурсов), и пользователь может войти в систему, используя учетные данные из своего домашнего клиента. Администраторы также могут использовать совместную работу B2B, чтобы внешние пользователи могли выполнять вход с помощью существующих учетных записей социальных сетей или организаций, настраивая федерацию с поставщиками удостоверений, такими как Facebook, учетные записи Майкрософт, Google или поставщик корпоративных удостоверений.
Участники и гости
Пользователи в клиенте Microsoft Entra являются членами или гостями на основе их свойства UserType. По умолчанию пользователями-членами являются пользователи, которые являются собственными для клиента. Пользователь Microsoft Entra B2B для совместной работы добавляется как пользователь с UserType = Guest по умолчанию. Гости имеют ограниченные разрешения в каталоге и приложениях. Например, гостевые пользователи не могут просматривать сведения из клиента, кроме сведений о своем профиле. Однако гостевой пользователь может получить сведения о другом пользователе, указав имя участника-пользователя (UPN) или objectId. Гостевой пользователь также может считывать свойства групп, к которых он принадлежит, включая членство в группах, независимо от того, какие разрешения гостевых пользователей ограничены .
В некоторых случаях клиенту ресурсов может потребоваться рассматривать пользователей из домашнего клиента как участников, а не гостей. Если это так, вы можете использовать API диспетчера приглашений Microsoft Entra B2B, чтобы добавить или пригласить пользователя из домашнего клиента в клиент ресурсов в качестве участника. Дополнительные сведения см. в разделе Свойства пользователя Microsoft Entra совместной работы B2B.
Централизованное администрирование нескольких клиентов
Подключение внешних удостоверений с помощью Microsoft Entra B2B. Затем внешним удостоверениям можно назначить привилегированные роли для управления Microsoft Entra арендаторами в качестве членов централизованной ИТ-команды. Вы также можете использовать Microsoft Entra B2B для создания гостевых учетных записей для других сотрудников, таких как администраторы на уровне региона или района.
Однако для ролей, относящихся к службе, таких как администратор Exchange или администратор SharePoint, требуется локальная учетная запись, которая является собственной для их клиента.
Учетным записям B2B можно назначить следующие роли.
Администратор приложений
Разработчик приложения
Администратор проверки подлинности
Администратор набора ключей IEF B2C
Администратор политики IEF B2C
Администратор политики IEF облачного приложения B2C
Администратор политики IEF для облачных устройств B2C
Администратор условного доступа
Администраторы устройств
Присоединение устройства
Пользователи устройств
Читатели каталогов
Запись каталогов
Учетные записи синхронизации каталогов
Администратор потока пользователей с внешним идентификатором
Администратор атрибутов потока пользователя внешнего идентификатора
Внешний поставщик удостоверений
Администратор групп
Приглашающий гостей
Администратор службы поддержки
Администратор гибридных удостоверений
Администратор службы Intune
Администратор лицензий
Администратор паролей
Привилегированный администратор проверки подлинности
Администратор привилегированных ролей
Читатель отчетов
Ограниченный гостевой пользователь
Администратор безопасности
Читатель сведений о безопасности
Администратор учетных записей пользователей
Присоединение к рабочему месту устройства
Пользовательские роли администратора в Microsoft Entra ID отображают базовые разрешения встроенных ролей, чтобы можно было создавать и упорядочивать собственные пользовательские роли. Такой подход позволяет предоставлять доступ более детализированным способом, чем встроенные роли, когда они необходимы.
Ниже приведен пример, показывающий, как будет работать администрирование для административных ролей, которые можно делегировать и использовать в нескольких клиентах.
Собственная учетная запись Susie находится в клиенте Region 1, а Microsoft Entra B2B используется для добавления учетной записи в качестве администратора проверки подлинности в центральную ИТ-команду в клиентах для региона 2 и региона 3.
Использование приложений в нескольких клиентах
Чтобы устранить проблемы, связанные с администрированием приложений в мультитенантной среде, следует рассмотреть возможность написания мультитенантных приложений. Кроме того, необходимо проверить, какое из приложений SaaS поддерживает несколько подключений поставщика удостоверений. Приложения SaaS, поддерживающие несколько подключений поставщика удостоверений, должны настраивать отдельные подключения для каждого клиента. Приложениям SaaS, которые не поддерживают несколько подключений поставщика удостоверений, могут потребоваться независимые экземпляры. Дополнительные сведения см. в статье Практическое руководство. Вход в любой Microsoft Entra пользователя с помощью шаблона мультитенантного приложения.
Примечание. Модели лицензирования могут отличаться от одного приложения SaaS к другому. проверка с поставщиком, чтобы определить, потребуется ли несколько подписок в мультитенантной среде.
Администрирование для каждого клиента
Для ролей, относящихся к службе, требуется администрирование для каждого клиента. Для ролей, относящихся к службе, требуется локальная учетная запись, которая является собственной для клиента. Помимо централизованной ИТ-команды в каждом клиенте, вам также потребуется региональная ИТ-команда в каждом клиенте для управления рабочими нагрузками, такими как Exchange, SharePoint и Teams.
Для следующих ролей требуются собственные учетные записи для каждого клиента.
Администратор Azure DevOps
Администратор Information Protection Azure
Администратор выставления счетов
Администратор службы CRM
Администратор соответствия требованиям
Администратор данных соответствия требованиям
Утверждающий доступ к защищенному хранилищу
Администратор Аналитика компьютеров
Администратор Exchange
Администратор Insights
Аналитика для руководителей компаний
Администратор Kaizala
Администратор службы Lync
Средство чтения конфиденциальности Центра сообщений
Читатель центра сообщений
Администратор принтера
Технический специалист по принтерам
Администратор поиска
Поиск Редактор
Оператор безопасности
Администратор поддержки служб
Администратор SharePoint
Администратор связи Teams
Инженер службы поддержки связи Teams
Специалист службы поддержки связи Teams
Администратор службы Teams
Уникальные администраторы в каждом клиенте
Если у вас есть ИТ-команда, собственная для каждого региона, вы можете заставить одного из этих локальных администраторов управлять администрированием Teams. В следующем примере Чарльз находится в клиенте Region 1 и имеет роль администратора службы Teams. Алиса и Итиро находятся в регионах 2 и 3 соответственно и занимают одну и ту же роль в своих регионах. У каждого локального администратора есть одна собственная учетная запись для своего региона.
Администратор роли в разных клиентах
Если у вас нет локального пула администраторов в каждом регионе, можно назначить роль администратора службы Teams только одному пользователю. В этом сценарии, как показано ниже, вы можете задействовать Боба из центральной ИТ-команды в качестве администратора службы Teams во всех трех клиентах, создав локальную учетную запись для Bob в каждом клиенте.
Делегирование ролей администратора в клиенте
Административные единицы (AU) должны использоваться для логического группирования Microsoft Entra пользователей и групп. Ограничение административных область с использованием административных единиц полезно в образовательных организациях, состоящих из различных регионов, районов или школ.
Например, наша вымышленная школа изобразительных искусств распределена по трем регионам, каждый из которых содержит несколько школ. В каждом регионе есть команда ИТ-администраторов, которые управляют доступом, управляют пользователями и задают политики для соответствующих учебных заведений.
Например, ИТ-администратор может:
Создайте au для пользователей каждого из учебных заведений в регионе 1, чтобы управлять всеми пользователями в этом учебном заведении. (не изображено)
Создайте au, содержащий преподавателей в каждом учебном заведении, для управления учетными записями преподавателей.
Создайте отдельный au, содержащий учащихся в каждом учебном заведении, для управления учетными записями учащихся.
Назначьте преподавателям в учебном заведении роль администратора паролей для центра обучения учащихся, чтобы преподаватели могли сбрасывать пароли учащихся, но не сбрасывать пароли других пользователей.
К ролям, которые могут быть ограничены административными единицами, относятся:
Администратор проверки подлинности
Администратор групп
Администратор службы поддержки
Администратор лицензий
Администратор паролей
Администратор пользователей
Дополнительные сведения см. в статье Назначение ролей с заданной областью административной единице.
Управление между клиентами
Параметры настраиваются в каждом клиенте по отдельности. Затем настройте в рамках создания клиента, где это возможно, чтобы свести к минимуму необходимость повторного изменения этих параметров. Хотя некоторые распространенные задачи можно автоматизировать, встроенный портал управления между клиентами отсутствует.
Управление объектами в большом масштабе
Microsoft Graph (MS Graph) и Microsoft Graph PowerShell позволяют управлять объектами каталогов в большом масштабе. Их также можно использовать для управления большинством политик и параметров в клиенте. Однако следует учитывать следующие аспекты производительности:
MS Graph ограничивает создание пользователей, групп и изменение членства 72 000 на каждого клиента в час.
На производительность MS Graph могут влиять действия, управляемые пользователем, такие как операции чтения или записи в клиенте.
Производительность MS Graph может быть затронута другими конкурирующими задачами ИТ-администратора в клиенте
PowerShell, SDS, Microsoft Entra Connect и пользовательские решения подготовки добавляют объекты и членства через MS Graph с разной скоростью.
Дальнейшие действия
Если вы еще не ознакомились с разделом Общие сведения о клиентах Microsoft Entra, вы можете сделать это. См. следующие статьи: