Конфигурация нулевого доверия для мультитенантных организаций защиты

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

Рис. 1. Пример многотенантной архитектуры защиты с конфигурациями нулевого доверия.

Определение архитектуры удостоверений

Клиенты Microsoft Entra являются основой архитектуры удостоверений. Клиент — это граница удостоверения в идентификаторе Microsoft Entra. Организация с одним клиентом Microsoft Entra имеет одну архитектуру клиента. Организации, использующие несколько клиентов Microsoft Entra, имеют многотенантную архитектуру.

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

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

Таблица 1. Причины создания или создания нескольких клиентов.

Причина	Пример
Для конфиденциальности или безопасности требуется более глубокое разделение данных	У организации Генерального инспектора должна быть независимость.
Делегирование и сегментация администрирования	У одной организации нет возможности управлять другой организацией.
Суверенитет и/или владение данными	У одной организации нет юридического органа для управления данными другой организации.
Сеть и ИТ-организация	Невозможно и не выгодно свернуть несколько крупных корпоративных ИТ-архитектур в единую корпоративную архитектуру.
Мониторинг и реагирование на инциденты SOC	SOC должен иметь отдельный клиент для управления своими ролями и обязанностями.

Если требуется несколько клиентов Microsoft Entra, следует использовать Внешняя идентификация Microsoft Entra (B2B) и Azure Lighthouse. Эти функции помогают поддерживать мультитенантные среды защиты. Дополнительные сведения см. в моделях аренды для мультитенантного решения.

Определение типов клиентов

Многотенантные организации защиты могут классифицировать экземпляры Microsoft Entra, которые они используют как первичные или вторичные. Каждая организация должна определять и назначать один клиент в качестве основного клиента. Все остальные клиенты являются вторичными. На рисунке 1 показана организация обороны с основным клиентом и n вторичными клиентами (показаны два вторичных клиента).

Определите основной клиент. Большинство организаций защиты создают основной клиент при регистрации в Microsoft 365. Основной клиент содержит (1) все удостоверения пользователей и лицензии Microsoft 365, (2) устройства и (3) приложения (см. рис. 1). Организации защиты часто используют Microsoft Entra Подключение для синхронизации удостоверений из локальной среды Active Directory с основным клиентом Microsoft Entra.

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

Определите все вторичные клиенты (если мультитенантные). Все остальные клиенты, которыми управляет организация, являются вторичными клиентами. Возможно, у вас есть вторичные клиенты, если вы переносите приложения в облако, прежде чем стоять в целевой зоне Azure корпоративного масштаба. Обычно для управления рабочими нагрузками Azure (4) с внешними пользователями (гостями B2B) или (5) облачными учетными записями (см. рис. 1).

Используйте дерево принятия решений. Самый простой способ найти основной клиент — рассмотреть лицензии удостоверений, которые у вас есть в идентификаторе Microsoft Entra.

Клиент с лицензиями Microsoft 365 является основным клиентом (см. рис. 2). Основной клиент может не быть первым клиентом, созданным вашей организацией, но он должен быть основным клиентом со всеми пользователями и лицензиями Microsoft 365.

Если ваша организация не использует Microsoft 365, любой клиент Microsoft Entra с лицензиями Enterprise Mobility and Security (EMS) является вашим основным клиентом. В этом клиенте вы добавили и проверили доменное имя вашей организации. Клиент часто использует гибридное удостоверение или интегрируется с системой кадров (HR) (см. рис. 2).

Рисунок 2. Дерево принятия решений для определения основного клиента и вторичного клиента Microsoft Entra.

Чтобы установить идентификатор Microsoft Entra как платформу нулевого доверия, вам потребуется клиент, заполненный удостоверениями пользователей и лицензированными для политик доступа на основе пользователей и устройств. Лицензирование Microsoft 365 объединяет эти возможности нулевого доверия с Office 365. Если вы не используете Microsoft 365, рассмотрите возможность enterprise Mobility + Security E5 , чтобы установить облачный поставщик удостоверений для нулевого доверия. Дополнительные сведения см. в разделе "Выбор центра идентификации".

Настройка нулевого доверия

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

Дополнительные сведения о защите клиентов Microsoft Entra с нулевым доверием см. в статье "План быстрого модернизации нулевого доверия" и план быстрой модернизации системы безопасности.

Все клиенты

Вы должны реализовать следующие рекомендации во всех клиентах Microsoft Entra.

Создание учетных записей и процедур аварийного доступа. Создайте две или более учетных записей аварийного доступа, чтобы избежать блокировки клиента Microsoft Entra. Для этих учетных записей необходимо назначить роль глобального Администратор istrator. Учетные записи должны быть облачными учетными записями. Облачные учетные записи используют домен *.onmicrosoft.com . Дополнительные сведения см. в разделе "Управление учетными записями администратора аварийного доступа".

Защита идентификатора Microsoft Entra от локальных атак. Следуйте рекомендациям, описанным в разделе "Защита привилегированного доступа". Только назначьте разрешения Microsoft Entra облачным учетным записям пользователей с помощью фишинговых учетных данных, таких как пароль оборудования или проверка подлинности на основе сертификатов. Не используйте федеративные удостоверения для административных целей. Дополнительные сведения см. в статье "Защита Microsoft 365 от локальных атак".

Используйте технологию управления привилегированными пользователями. Используйте microsoft Entra управление привилегированными пользователями (PIM) для управления назначениями ролей для ролей Microsoft Entra ID и ролей Azure. Вы также должны использовать PIM для управления соответствующим членством в группах для привилегированных групп безопасности. Установите периодические проверки доступа для соответствующих администраторов и внешних пользователей (гостей B2B).

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

Проверка подлинности на основе сертификатов (CBA) в Microsoft Entra делает его ненужным для федерации доменов Microsoft Entra. Проверка подлинности Microsoft Entra поддерживает следующие методы проверки подлинности без пароля:

• Ключи доступа (ключи безопасности FIDO2)
• Проверка подлинности на основе сертификатов
• Microsoft Authenticator
• Windows Hello для бизнеса

Установите базовые политики условного доступа. Базовые показатели условного доступа зависят от организации и требований. Установите основной набор политик условного доступа для всех клиентов Microsoft Entra. Используйте удостоверения, устройства, приложения и условия риска в наборе политик. Исключите учетные записи аварийного доступа из политик условного доступа.

Защита идентификации Microsoft Entra помогает организациям обнаруживать, исследовать и устранять риски на основе удостоверений. Чтобы защитить рискованные входы и пользователей, создайте политики условного доступа с условиями риска. Используйте отдельные политики для рискованных пользователей и рискованных входов. Увеличьте применяемые элементы управления с уровнем риска для каждого типа риска. Чтобы сбалансировать производительность пользователей с безопасностью, не используйте элемент управления "Блокировать " в политиках на основе рисков.

Примечание.

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

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

Внимание

Пользователи без пароля, которые войдите только с помощью методов без пароля, таких как проверка подлинности на основе сертификатов, пароль или Windows Hello для бизнеса, могут быть заблокированы элементом управления "Требовать изменение пароля", если он не может сбросить пароль в идентификаторе Microsoft Entra ID.

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

Таблица 2. Пример политики условного доступа проверка list.

Имя политики	Пользователи	Приложения	Условия	Предоставление элемента управления
MFA для всех пользователей	Все пользователи	Все приложения	нет	- Фишинго-устойчивый MFA
Требовать управляемое устройство	Все пользователи	Все приложения	нет	- Требовать гибридное присоединение или соответствие устройству Microsoft Entra
Защита входов среднего риска	Все пользователи	Все приложения	Средний риск входа	- Фишинго-устойчивый MFA - Требовать соответствующее устройство - Частота входа: 1 час (настройте в соответствии с допустимой вероятностью риска вашей организации)
Защита входов с высоким уровнем риска	Все пользователи	Все приложения	Высокий риск входа	- Фишинго-устойчивый MFA - Требовать соответствующее устройство - Частота входа: каждый раз
Защита пользователей с высоким риском	Все пользователи	Все приложения	Высокий риск пользователя	- Фишинго-устойчивый MFA - Требовать соответствующее устройство - Частота входа: каждый раз
Безопасное администрирование Microsoft Entra	Роли Microsoft Entra	Все приложения	нет	- Фишинго-устойчивый MFA — требуется рабочая станция привилегированного доступа (PAW) с помощью фильтров устройств
Безопасное управление облаком	Все пользователи	Управление и безопасность Google Cloud Platform Amazon Web Services	нет	- Фишинго-устойчивый MFA — требуется рабочая станция привилегированного доступа (PAW) с помощью фильтров устройств

Пример политики, заданный в таблице 2 , — это для организаций без пароля, где все пользователи используют только фишинговый MFA с управляемых устройств. Привилегированные пользователи используют рабочие станции привилегированного доступа intune (PAW). Вместо того, чтобы требовать изменения пароля для пользователей с высоким риском, политика рискованных пользователей применяет проверку подлинности и контроль частоты входа. Эти элементы управления предлагают некоторые средства защиты, но не устраняют уровень риска пользователя в Защита идентификации Microsoft Entra. Ваша группа по операциям безопасности должна исследовать и устранять пользователей с высоким риском.

Дополнительные сведения о развертывании условного доступа см. в статье Планирование развертывания условного доступа.

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

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

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

Используйте идентификатор Microsoft Entra для управления другими облачными средами. Идентификатор Microsoft Entra — это не только платформа удостоверений Для Azure и Microsoft 365. Используйте идентификатор Microsoft Entra для получения доступа к другим облачным средам. Эти среды включают популярные продукты программного обеспечения как услуга (SaaS) и облачные платформы, такие как Amazon Web Services (AWS) и Google Cloud Platform (GCP). Дополнительные сведения см. в коллекции приложений Microsoft Entra.

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

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

Используйте Управление разрешениями Microsoft Entra. Управление разрешениями Microsoft Entra — это решение для управления правами облачной инфраструктуры (CIEM). Для видимости разрешений, назначенных всем удостоверениям, следует использовать Управление разрешениями Microsoft Entra. Вы также должны использовать его для отслеживания разрешений в многооблачной среде вашей организации.

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

Защита удостоверений рабочей нагрузки. Используйте Идентификация рабочей нагрузки Microsoft Entra функции для управления и применения политик адаптивного нулевого доверия для удостоверений приложений (субъектов-служб) в идентификаторе Microsoft Entra ID.

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

Разверните Sentinel и подключите все доступные источники данных. Агрегированные сигналы безопасности в SIEM, например Microsoft Sentinel. Разверните Sentinel и подключите все источники данных сигнала безопасности, настроив соединители данных.

Основные клиенты

В основном клиенте следует реализовать следующие рекомендации.

У конечных пользователей есть только одно удостоверение в идентификаторе Entra.Синхронизация локальная служба Active Directory доменных служб с основным клиентом Microsoft Entra. Синхронизация заполняет идентификатор Microsoft Entra пользователями, группами и устройствами для организации. Внешние гости B2B могут существовать в дополнительных клиентах, но пользователям нужно помнить только одно имя пользователя для всех приложений и служб. Результаты взаимодействия с пользователем и нулевым доверием лучшие при использовании удостоверений в основном клиенте для входа в Windows и доступа к приложению.

Присоединение устройств к основному клиенту и управление ими. Основной клиент Microsoft Entra содержит всех пользователей и устройств в организации. Присоединение к Microsoft Entra (или гибридное присоединение Microsoft Entra) к основному клиенту и управление ими с помощью Microsoft Intune. Используйте политику Intune для развертывания Microsoft Defender для конечной точки включения расширенных возможностей обнаружения и ответа (XDR).

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

Присоединение служб platform-as-a-service (PaaS), которым требуется удостоверение пользователя. Некоторые службы PaaS, такие как Файлы Azure и виртуальный рабочий стол Azure, зависят от конфигурации гибридных удостоверений или прав лицензии. Эти службы необходимо развернуть в подписках Azure в основном клиенте.

Вторичные клиенты

В дополнительном клиенте следует реализовать следующие рекомендации.

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

Удостоверения пользователей. Необходимо иметь лицензии Microsoft Entra ID Premium P2 для администраторов клиентов и учетных записей аварийного доступа. Если вы используете модель управления внешним удостоверением (гостевая модель B2B), необходимо назначить по крайней мере одну лицензию Microsoft Entra ID Premium P2 локальному пользователю в клиенте. Эта настройка позволяет включить функции уровня "Премиум", такие как условный доступ и защита идентификации. Дополнительные сведения см . в общих рекомендациях по управлению мультитенантными пользователями.

Удостоверения рабочей нагрузки. Необходимо использовать удостоверения рабочей нагрузки premium для защиты удостоверений рабочей нагрузки с доступом к ресурсам в основном клиенте, например API MS Graph.

Управление устройствами. Возможно, вам потребуется управлять устройствами с помощью Microsoft Intune в дополнительном клиенте. В этом случае необходимо получить лицензии Enterprise Mobility and Security (EMS).

Настройте политики доступа между клиентами (XTAP). Внешняя идентификация Microsoft Entra (совместная работа Microsoft Entra B2B) между клиентами позволяют вторичному клиенту доверять определенным утверждениям из основного клиента дома. Добавьте основной клиент Microsoft Entra в качестве организации и обновите параметры доверия для входящего трафика, чтобы включить:

• Доверять многофакторной проверке подлинности (MFA) из клиентов Microsoft Entra
• Доверять устройствам, соответствующим требованиям
• Доверять гибридным устройствам, присоединенным к Microsoft Entra
• Необязательно. Автоматическое активация приглашений с клиентом

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

Используйте Azure Lighthouse для упрощения доступа Sentinel из основного клиента.Azure Lighthouse предоставляет другой способ управления Azure между клиентами. Azure Lighthouse использует шаблоны Azure Resource Manager (ARM) для назначения ролей Azure удостоверениям во внешнем клиенте. Этот подход не использует объекты гостевых пользователей B2B. Когда администратор входит на портал для управления Azure, они видят все ресурсы во всех клиентах. Это консолидированное представление включает подписки с разрешениями, назначенными Azure Lighthouse. Так как гостевой объект B2B отсутствует, администратору не нужно переключать каталоги. Используйте Azure Lighthouse для упрощения управления Microsoft Sentinel в клиентах.

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

Управление мультитенантными операциями

Дополнительные ссылки

• Основные сведения об удостоверениях
• Конфигурации нулевого доверия
• Централизованные операции безопасности