Гибридное удостоверение с идентификатором Active Directory и Microsoft Entra в целевых зонах Azure

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

Организациям, работающим в облаке, требуется служба каталогов для управления удостоверениями пользователей и доступом к ресурсам. Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом, которая предоставляет надежные возможности для управления пользователями и группами. Его можно использовать в качестве автономного решения для удостоверений или интегрировать его с инфраструктурой доменных служб Microsoft Entra или инфраструктурой локальная служба Active Directory доменных служб (AD DS).

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

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

С течением времени измените решение для идентификации в зависимости от требований к проверке подлинности рабочей нагрузки и других потребностей, таких как изменения стратегии идентификации организации и требования к безопасности, а также интеграция с другими службами каталогов. При оценке решений Active Directory понять различия между идентификатором Microsoft Entra, доменными службами и AD DS в Windows Server.

Сведения о стратегии идентификации см . в руководстве по принятию решений по идентификации.

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

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

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

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

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

Azure и локальные домены (гибридное удостоверение)

Пользовательские объекты, созданные полностью в идентификаторе Microsoft Entra, называются облачными учетными записями. Они поддерживают современную проверку подлинности и доступ к ресурсам Azure и Microsoft 365, а также доступ к локальным устройствам, используюющим Windows 10 или Windows 11.

Однако многие организации уже имеют давние каталоги AD DS, которые могут быть интегрированы с другими системами, такими как планирование бизнес-ресурсов или планирование корпоративных ресурсов (ERP) через протокол LDAP. Эти домены могут иметь множество присоединенных к домену компьютеров и приложений, использующих протоколы Kerberos или более старых протоколов NTLMv2 для проверки подлинности. В этих средах можно синхронизировать объекты пользователей с идентификатором Microsoft Entra, чтобы пользователи могли войти как в локальные системы, так и в облачные ресурсы с одним удостоверением. Объединение локальных и облачных служб каталогов называется гибридным удостоверением. Локальные домены можно расширить в целевые зоны Azure:

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

• Чтобы присоединиться к виртуальным машинам Windows и другим службам, можно развернуть контроллеры домена AD DS или доменные службы в Azure. С помощью этого подхода пользователи AD DS могут входить на серверы Windows, Файлы Azure общие папки и другие ресурсы, использующие Active Directory в качестве источника проверки подлинности. Вы также можете использовать другие технологии Active Directory, такие как групповая политика. Дополнительные сведения см. в общих сценариях развертывания для доменных служб Microsoft Entra.

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

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

• Оцените требования к решению удостоверений путем понимания и документирования поставщика проверки подлинности, используемого каждым приложением. Рассмотрим проверки, которые помогут спланировать тип службы, которую должна использовать ваша организация. Дополнительные сведения см. в руководстве по сравнению Active Directory с идентификатором Записи Майкрософт и руководством по принятию решений об удостоверении.

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

• Не используйте прокси приложения Microsoft Entra для доступа к интрасети, так как она добавляет задержку в взаимодействие с пользователем. Дополнительные сведения см. в статье о планировании прокси приложения Microsoft Entra и рекомендации по безопасности прокси приложения Microsoft Entra.

• Рассмотрим различные методы, которые можно использовать для интеграции локальная служба Active Directory с Azure в соответствии с требованиями организации.

• Если у вас есть федерация службы федерации Active Directory (AD FS) (AD FS) с идентификатором Microsoft Entra ID, можно использовать синхронизацию хэша паролей в качестве резервной копии. AD FS не поддерживает простой единый вход (SSO) Microsoft Entra.

• Определите правильное средство синхронизации для удостоверений облака.

• Если у вас есть требования к использованию AD FS, см. статью "Развертывание AD FS в Azure".

Внимание

Мы настоятельно рекомендуем перейти на идентификатор Microsoft Entra, если только не существует определенного требования к использованию AD FS. Дополнительные сведения см. в разделе "Ресурсы" для вывода из эксплуатации AD FS и миграции с AD FS на идентификатор Microsoft Entra.

Идентификатор Microsoft Entra, доменные службы и AD DS

Администратор istrator должны ознакомиться с параметрами реализации служб каталогов Майкрософт:

• Контроллеры домена AD DS можно развернуть в Azure как виртуальные машины Windows, на которых платформа или администраторы удостоверений имеют полный контроль. Этот подход — это решение инфраструктуры как услуга (IaaS). Вы можете присоединить контроллеры домена к существующему домену Active Directory или разместить новый домен с необязательным отношением доверия с существующими локальными доменами. Дополнительные сведения см. в статье azure Виртуальные машины базовой архитектуры в целевой зоне Azure.

• Доменные службы — это управляемая Azure служба, которую можно использовать для создания нового управляемого домена Active Directory, размещенного в Azure. Домен может иметь отношение доверия с существующими доменами и может синхронизировать удостоверения из идентификатора Microsoft Entra. Администратор istrator не имеют прямого доступа к контроллерам домена и не несут ответственности за исправление и другие операции обслуживания.

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

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

Рекомендации Microsoft Entra ID и AD DS

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

• Оцените совместимость рабочих нагрузок для AD DS в Windows Server и доменных службах. Дополнительные сведения см. в распространенных вариантах использования и сценариях.

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

• Защитите виртуальную сеть, содержащую контроллеры домена. Запрет прямого подключения к Интернету и из этих систем путем размещения серверов AD DS в изолированной подсети с группой безопасности сети (NSG), предоставляя функциональные возможности брандмауэра. Ресурсы, использующие контроллеры домена для проверки подлинности, должны иметь сетевой маршрут к подсети контроллера домена. Включите только сетевой маршрут для приложений, которым требуется доступ к службам в подписке Identity. Дополнительные сведения см. в статье "Развертывание AD DS в виртуальной сети Azure".

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

• При развертывании контроллеров домена AD DS в Azure разверните их в зонах доступности для повышения устойчивости. Дополнительные сведения см. в разделе "Создание виртуальных машин в зонах доступности" и "Перенос виртуальных машин в зоны доступности".

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

• Если пользователю Windows требуется Kerberos для Файлы Azure общих папок, рекомендуется использовать проверку подлинности Kerberos для идентификатора Microsoft Entra ID, а не развертывать контроллеры домена в облаке.

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

Управление удостоверениями целевой зоны и доступом