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

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

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

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

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

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

Дополнительные сведения см . в руководстве по решению об удостоверении.

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

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

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

Разверните контроллеры домена и связанные компоненты, такие как серверы Microsoft Entra Подключение, в подписке 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 Cloud Sync. Чтобы определить рекомендуемую конфигурацию для вашей среды, ознакомьтесь с топологиями Microsoft Entra Подключение и топологиями для Microsoft Entra Cloud Sync.

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

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

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

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

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

• Чтобы расширить локальный экземпляр AD DS в Azure и оптимизировать развертывание, включите регионы Azure в проект сайта Active Directory. Создайте сайт на сайтах и службах AD DS для каждого региона Azure, в котором планируется развернуть рабочие нагрузки. Затем создайте новый объект подсети на сайтах и службах AD DS для каждого диапазона IP-адресов, который планируется развернуть в регионе. Свяжите новый объект подсети с созданным сайтом AD DS. Эта конфигурация гарантирует, что служба указателя контроллера домена направляет запросы авторизации и проверки подлинности к ближайшим контроллерам домена AD DS в том же регионе Azure.

• Оцените сценарии, которые настраивают гостей, клиентов или партнеров, чтобы они могли получить доступ к ресурсам. Определите, связаны ли эти сценарии с 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 Подключение в качестве средства синхронизации, рассмотрите возможность развертывания промежуточного сервера в регионе, отличном от основного сервера Microsoft Entra Подключение для аварийного восстановления. Кроме того, если вы не используете несколько регионов, реализуйте зоны доступности для обеспечения высокой доступности.

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

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

Чтобы реализовать службы каталогов Майкрософт, ознакомьтесь со следующими параметрами:

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

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

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

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

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

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

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

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

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

• Используйте Диспетчер виртуальная сеть Azure для применения стандартных правил, применяемых к виртуальным сетям. Например, можно использовать теги ресурсов Политика Azure или виртуальной сети для добавления виртуальных сетей целевой зоны в группу сети, если они требуют служб удостоверений Active Directory. Затем группу сети можно использовать, которая разрешает доступ к подсети контроллера домена только из приложений, которым требуется доступ, и блокировать доступ из других приложений.

• Защита разрешений управления доступом на основе ролей (RBAC), которые применяются к виртуальным машинам контроллера домена и другим ресурсам удостоверений. Администратор istrator с назначениями ролей RBAC на уровне управления Azure, например участник, владелец или участник виртуальной машины, может выполнять команды на виртуальных машинах. Убедитесь, что только авторизованные администраторы могут получить доступ к виртуальным машинам в подписке Identity, и что чрезмерно допустимые назначения ролей не наследуются от более высоких групп управления.

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

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

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

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

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