Основы управления ресурсами Azure

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

Терминология

Ниже приведены некоторые термины, с которыми вы должны ознакомиться:

Ресурсом называется управляемый элемент, доступный в Azure. Виртуальные машины, учетные записи хранения, веб-приложения, базы данных и виртуальные сети являются примерами ресурсов.

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

Подписка — с точки зрения иерархии организации это контейнер выставления счетов и управления для ресурсов и их групп. Между каждой подпиской Azure и Microsoft Entra ID установлено отношение доверия. Подписка доверяет Microsoft Entra ID проверку подлинности пользователей, служб и устройств.

Группа управления — - группы управления Azure предоставляют иерархический метод применения политик и обеспечивают соответствие требованиям в разных областях сверх подписок. Группа управления может находиться в корневой группе клиента (на самом верхнем уровне) или на более низких уровнях в иерархии. Подписки структурируются в контейнеры, называемые группами управления, и к группам управления применяются условия политики управления. Все подписки в группе управления автоматически наследуют условия, применяемые к группе управления. Обратите внимание, что определения политик можно применять к группе управления или подписке.

Поставщик ресурсов — служба, которая предоставляет ресурсы Azure. Например, распространенным поставщиком ресурсов является корпорация Майкрософт. Компьютер, поставляющий ресурс виртуальной машины. Корпорация Майкрософт. Еще одним распространенным поставщиком ресурсов является служба хранилища.

Шаблон Resource Manager — это файл в формате JSON (нотация объектов JavaScript), который определяет один или несколько ресурсов для развертывания в группе ресурсов, подписке, клиенте или группе управления. Шаблон можно использовать для согласованного и многократного развертывания ресурсов. См. общие сведения о развертывании шаблона. Кроме того, вместо JSON можно использовать язык Bicep.

Модель управления ресурсами Azure

Каждая подписка Azure связана с элементами управления, используемыми Azure Resource Manager. Resource Manager — это служба развертывания и управления для Azure, она имеет отношение доверия с Microsoft Entra ID для управления удостоверениями для организаций и учетной записью Microsoft (MSA) для отдельных лиц. Resource Manager обеспечивает уровень управления, позволяющий создавать, обновлять и удалять ресурсы в подписке Azure. Вы можете использовать функции управления этой службы, такие как управление доступом, блокировка и добавление тегов, чтобы защитить и упорядочить ресурсы после развертывания.

Azure Resource Manager — это интерфейсная служба, в которой размещаются интерфейсы REST API, используемые PowerShell, порталом Azure или другими клиентами для управления ресурсами. Когда клиент отправляет запрос на управление определенным ресурсом, Resource Manager проксирует этот запрос поставщику ресурсов для его выполнения. Например, если клиент отправляет запрос на управление ресурсом виртуальной машины, диспетчер ресурсов перенаправляет запрос компании Microsoft. Поставщик вычислительных ресурсов. Resource Manager требует, чтобы клиент указал идентификатор как для подписки, так и для группы ресурсов, чтобы управлять ресурсом виртуальной машины.

Перед выполнением Resource Manager любого запроса на управление ресурсом проверяется набор элементов управления.

• Допустимая проверка пользователя. Пользователь, запрашивающий управление ресурсом, должен иметь учетную запись в клиенте Microsoft Entra, связанном с подпиской управляемого ресурса.

• Проверка разрешений пользователя. Разрешения присваиваются пользователям с использованием механизма управления доступом на основе ролей (RBAC). Роль RBAC указывает набор разрешений, которые пользователь имеет в определенном ресурсе. RBAC позволяет управлять доступом пользователей к ресурсам Azure, включая настройку разрешений на выполнение операций с этими ресурсами и определением областей доступа.

• Проверка политики Azure. Политики Azure - задают операции, разрешенные или явно запрещенные для определенного ресурса. Например, в соответствии с политикой пользователям будет позволено (или не позволено) развертывать только определенные типы виртуальной машины.

Описанная здесь модель ресурсов в общем виде представлена на следующей схеме.

Azure Lighthouse - Azure Lighthouse обеспечивает управление ресурсами между подписчиками. Организации могут делегировать роли на уровне подписки или группы ресурсов удостоверениям в другом клиенте.

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

Стоит отметить, что центр управления Azure Lighthouse смоделирован как поставщик ресурсов Azure, благодаря чему можно настраивать аспекты делегирования по всему клиенту с помощью политик Azure.

Microsoft 365 Lighthouse. - Microsoft 365 Lighthouse — это портал администрирования, который помогает поставщикам управляемых служб (MSP) защищать и администрировать устройства, данные и пользователей в большом масштабе для клиентов малого и среднего бизнеса (SMB), использующих Microsoft 365 бизнес премиум, Microsoft 365 E3 или Windows 365 для бизнеса.

Управление ресурсами Azure с помощью идентификатора Microsoft Entra

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

Выставление счетов

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

Соглашения Azure Enterprise

Клиенты Соглашения Azure Enterprise (Azure EA) подключаются к порталу Azure EA Portal после заключения коммерческого контракта с корпорацией Майкрософт. При подключении удостоверение связывается с основной ролью администратора предприятия для выставления счетов. Портал предоставляет иерархию функций управления:

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

• Учетные записи используются для дальнейшего сегментирования отделов. Их можно использовать для управления подписками и доступа к отчетам. Портал EA может авторизовать учетные записи Майкрософт (MSA) или учетные записи Microsoft Entra (указанные на портале как "Рабочие или учебные учетные записи"). Удостоверения с ролью "Владелец учетной записи" на EA Portal позволяют создавать подписки Azure.

Корпоративное выставление счетов и арендаторы Microsoft Entra

Когда владелец учетной записи создает подписку Azure в рамках соглашения Enterprise, управление удостоверениями и доступом для подписки настраивается следующим образом:

• Подписка Azure связана с тем же клиентом Microsoft Entra, что и у владельца учетной записи.

• Владельцу учетной записи, создавшему подписку, будут назначены роли администратора службы и администратора учетной записи. (Портал Azure EA Portal назначает роли Azure Service Manager (ASM) или "классические роли" для управления подписками. Дополнительные сведения см. в статье Azure Resource Manager и классическое развертывание.)

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

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

Чтобы усилить изоляцию и предотвратить восстановление владельцем учетной записи доступа администратора службы к подписке, арендатор подписки может быть изменён после создания. Если у владельца учетной записи нет объекта пользователя в клиенте Microsoft Entra, в которую перемещается подписка, она не может восстановить роль владельца службы.

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

Клиентское соглашение Microsoft

Клиенты, зарегистрированные в Клиентское соглашение Майкрософт (MCA), имеют другую систему управления выставлением счетов с собственными ролями.

Учетная запись выставления счетов по Клиентскому соглашению Майкрософт содержит один или несколько профилей выставления счетов, которые позволяют управлять счетами и методами оплаты. Каждый профиль выставления счетов содержит один или несколько разделов счетов для упорядочения расходов в счете профиля выставления счетов.

В Клиентское соглашение Майкрософт роли выставления счетов приходят из одного клиента Microsoft Entra. Для того чтобы предоставить подписки для нескольких клиентов, подписки изначально должны быть созданы в том же клиенте Microsoft Entra, что и MCA, а затем изменены. На приведенной ниже схеме подписки для корпоративной подготовительной ИТ-среды перемещены в клиент ContosoSandbox после создания.

RBAC и назначения ролей в Azure

В разделе "Основы Microsoft Entra" вы узнали, что Azure RBAC — это система авторизации, которая обеспечивает точное управление доступом к ресурсам Azure и включает множество встроенных ролей. Вы можете создавать пользовательские роли и назначать роли в разных областях. Разрешения применяются путем назначения ролей RBAC объектам, запрашивающим доступ к ресурсам Azure.

Роли Microsoft Entra основаны на таких понятиях, как управление доступом на основе ролей Azure. Разница между этими двумя системами управления доступом на основе ролей заключается в том, что Azure RBAC использует Azure Resource Management для управления доступом к ресурсам Azure, таким как виртуальные машины или хранилище, и роли Microsoft Entra управляют доступом к идентификатору Microsoft Entra ID, приложениям и службы Майкрософт таким как Office 365.

Роли Microsoft Entra и роли Azure RBAC интегрируются с Microsoft Entra Privileged Identity Management для включения политик активации по требованию, таких как рабочий процесс утверждения и многофакторная аутентификация (MFA).

RBAC и назначения ролей в Azure

Управление доступом на основе атрибутов (ABAC) — это система авторизации, которая определяет доступ на основе атрибутов, связанных с субъектами безопасности, ресурсами и средой. С помощью ABAC можно предоставить субъекту безопасности доступ к ресурсу на основе атрибутов. Azure ABAC — это реализация ABAC для Azure.

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

Условный доступ

Условный доступ Microsoft Entra можно использовать для управления доступом к конечным точкам управления Azure. Политики условного доступа можно применить к облачному приложению API управления службами Windows Azure для защиты конечных точек управления ресурсами Azure, таких как:

• Поставщик Azure Resource Manager (службы)

• API системы управления ресурсами Azure

• Azure PowerShell

• Azure CLI (Интерфейс командной строки для Azure)

• Портал Azure

Например, администратор может настроить политику условного доступа, которая позволяет пользователю входить в портал Azure только из утвержденных расположений, а также требовать многофакторную проверку подлинности (MFA) или гибридное устройство, присоединенное к домену Microsoft Entra.

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

Распространенная проблема при создании облачных приложений — управление учетными данными в коде для проверки подлинности в облачных службах. Обеспечение безопасности учетных данных является важной задачей. В идеальном случае учетные данные никогда не попадают на рабочие станции разработчиков и не коммитятся в систему контроля версий. Управляемые удостоверения для ресурсов Azure предоставляют службам Azure автоматически управляемую идентичность в Microsoft Entra ID. Удостоверение можно использовать для проверки подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra без каких-либо учетных данных в коде.

Существует два типа управляемых удостоверений:

• Управляемое системное удостоверение включается непосредственно в ресурс Azure. Когда ресурс включен, Azure создает идентификацию для ресурса в доверенном арендаторе Microsoft Entra связанной с подпиской. После создания идентификатора учетные данные размещаются на ресурсе. Жизненный цикл назначаемого системой удостоверения напрямую связан с ресурсом Azure. Если ресурс удален, Azure автоматически очищает учетные данные и удостоверение в идентификаторе Microsoft Entra.

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

Внутренне управляемые удостоверения являются служебными принципалами особого типа, предназначенными исключительно для использования определенными ресурсами Azure. При удалении управляемого удостоверения соответствующий сервисный принципал автоматически удаляется. Заметьте, что авторизация разрешений Graph API может выполняться только с помощью PowerShell, поэтому не все функции Managed Identity доступны в пользовательском интерфейсе Портала.

Доменные службы Microsoft Entra

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

Каталоги Azure AD B2C и Azure

Клиент Azure AD B2C связан с подпиской Azure с целью обеспечения выставления счетов и обмена данными. Клиенты Azure AD B2C имеют автономную структуру ролей в каталоге, которая не зависит от привилегированных ролей Azure RBAC подписки Azure.

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

Важно отметить, что владельцы и участники связанной подписки Microsoft Entra могут удалить связь между подпиской и каталогом, что повлияет на текущее выставление счетов за использование Azure AD B2C.

Рекомендации по идентификации для решений IaaS в Azure

В этом сценарии рассматриваются требования к изоляции удостоверений, которые должны соблюдаться организациями для рабочих нагрузок "Инфраструктура как услуга" (IaaS).

Существует три основных варианта управления изоляцией рабочих нагрузок IaaS:

• виртуальные машины, присоединенные к автономным доменным службам Active Directory (AD DS);

• Виртуальные машины, присоединенные к доменным службам Microsoft Entra

• Вход на виртуальные машины в Azure с помощью проверки подлинности Microsoft Entra

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

• При входе на виртуальную машину Windows Server Azure с помощью протокола удаленного рабочего стола (RDP) обычно выполняется вход на сервер с помощью учетных данных домена, который выполняет проверку подлинности Kerberos для локального контроллера домена AD DS или доменных служб Microsoft Entra. Кроме того, если сервер не присоединен к домену, для входа в виртуальные машины может использоваться локальная учетная запись.

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

Виртуальные машины, присоединенные к автономным доменным службам Active Directory

AD DS — это служба каталогов на основе Windows Server, которая широко используется организациями для локальных служб идентификации. AD DS можно развернуть, если необходимо развертывание рабочих нагрузок IaaS в Azure, что требует изоляции идентификации от администраторов AD DS и пользователей в другом лесу.

В этом сценарии необходимо учитывать следующие факторы:

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

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

• Службы доменных имен AD DS (DNS). Чтобы обеспечить правильное выполнение разрешения имен для серверов и приложений, необходимо настроить AD DS DNS для соответствующих зон в AD DS.

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

• Роли FSMO в AD DS. Необходимые роли гибких операций с одним исполнителем (FSMO) необходимо проверить и назначить соответствующим контроллерам домена AD DS.

• Присоединение к домену AD DS — все серверы (за исключением jumpboxes), которые требуют AD DS для проверки подлинности, конфигурации и управления, должны быть присоединены к изолированному лесу.

• Групповая политика AD DS (GPO) — объекты групповой политики AD DS должны быть настроены для обеспечения соответствия требованиям безопасности и стандартизации конфигурации на компьютерах, присоединенных к лесу и домену.

• Подразделения AD DS. Чтобы обеспечить группирование ресурсов AD DS в логические изолированные подразделения управления и настройки, используемые для администрирования и применения конфигурации, необходимо определить подразделения AD DS.

• Управление доступом на основе ролей (RBAC) должно быть определено для администрирования и доступа к ресурсам, присоединенным к этому лесу. Сюда входит следующее:

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

  • Учетные записи администрирования. Как упоминалось в начале этого раздела, для управления этим решением требуются две учетные записи администрирования.

    • Учетная запись администрирования AD DS с минимально привилегированным доступом, необходимая для выполнения необходимого администрирования в AD DS и на серверах, присоединенных к домену.

    • Учетная запись администрирования Microsoft Entra для доступа к порталу Azure, чтобы подключать, управлять и настраивать виртуальные машины, виртуальные сети (VNets), группы безопасности сети и другие необходимые ресурсы Azure.

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

Виртуальные сети: руководство по настройке

• IP-адрес контроллера домена AD DS. Контроллеры домена не должны быть настроены со статическими IP-адресами в операционной системе. IP-адреса должны быть зарезервированы в виртуальной сети Azure, чтобы они всегда оставались неизменными, а контроллер домена должен быть настроен для использования DHCP.

• DNS-сервер виртуальной сети. DNS-серверы должны быть настроены в виртуальных сетях, которые являются частью этого изолированного решения, так, чтобы они указывали на контроллеры домена. Это необходимо для того, чтобы приложения и серверы могли разрешать доступ к необходимым службам AD DS или другим службам, присоединённым к этому лесу AD DS.

• Группы безопасности сети (NSG). Контроллеры домена должны находиться в собственной виртуальной сети или подсети с группами безопасности сети, определенными так, чтобы доступ к контроллерам домена можно было получить только с необходимых серверов (например, присоединенных к домену компьютеров или серверов jumpbox). Чтобы упростить создание и администрирование NSG, Jumpboxes следует добавить в группу безопасности приложений (ASG).

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

• Дополнительный лес Active Directory для администрирования, управления и мониторинга приводит к увеличению объема работы для ИТ-команды.

• Для управления исправлениями и развертываниями программного обеспечения может потребоваться дополнительная инфраструктура. Организациям следует рассмотреть возможность развертывания Управления обновлениями Azure, групповой политики (GPO) или System Center Configuration Manager (SCCM) для управления этими серверами.

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

Виртуальные машины, присоединенные к доменным службам Microsoft Entra

Если необходимо развернуть рабочие нагрузки IaaS в Azure, для которых требуется изоляция учетных данных от администраторов и пользователей AD DS в другом лесу, можно развернуть управляемый домен в Microsoft Entra Domain Services. Доменные службы Microsoft Entra — это служба, которая предоставляет управляемый домен для упрощения проверки подлинности для рабочих нагрузок Azure с помощью устаревших протоколов. Это обеспечивает наличие изолированного домена без технических сложностей, связанных с созданием собственных доменных служб Active Directory и управлением ими. При этом необходимо учитывать следующие факторы.

Управляемый домен доменных служб Microsoft Entra— можно развернуть только один управляемый домен доменных служб Microsoft Entra для каждого клиента Microsoft Entra, и это привязано к одной виртуальной сети. Рекомендуется, чтобы эта виртуальная сеть формовала "концентратор" для проверки подлинности доменных служб Microsoft Entra. В этом концентраторе можно создать и связать «спицы», чтобы разрешить устаревшую аутентификацию для серверов и приложений. Периферийные сети являются дополнительными виртуальными сетями, на которых расположены серверы, присоединенные к Microsoft Entra Domain Services, и связываются с концентратором с помощью сетевых шлюзов Azure или пиринга виртуальных сетей.

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

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

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

Провизия объектов. Доменные службы Microsoft Entra синхронизируют удостоверения из Microsoft Entra ID, связанного с подпиской, в которой развернуты доменные службы Microsoft Entra. Кроме того, следует отметить, что если связанный идентификатор Microsoft Entra ID настроен на синхронизацию с Microsoft Entra Connect (в случае пользовательского леса), жизненный цикл данных идентификаторов также может отражаться в доменных службах Microsoft Entra. Эта служба имеет два режима, которые можно использовать для подготовки объектов пользователей и групп из идентификатора Microsoft Entra.

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

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

При первом развертывании доменных служб Microsoft Entra автоматическая односторонняя синхронизация настраивается для репликации объектов из идентификатора Microsoft Entra. Эта односторонняя синхронизация продолжает выполняться в фоновом режиме, чтобы управляемый домен службы доменов Microsoft Entra оставался в актуальном состоянии с учётом всех изменений из Microsoft Entra ID. Синхронизация не выполняется от доменных служб Microsoft Entra обратно к Microsoft Entra ID. Дополнительные сведения см. в статье о синхронизации объектов и учетных данных в управляемом домене доменных служб Microsoft Entra.

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

Объекты групповой политики (GPO) — чтобы настроить объект групповой политики в управляемом домене доменных служб Microsoft Entra, необходимо использовать средства управления групповыми политиками на сервере, присоединенном к управляемому домену доменных служб Microsoft Entra. Дополнительные сведения см. в разделе "Администрирование групповой политики" в управляемом домене доменных служб Microsoft Entra.

Secure LDAP — доменные службы Microsoft Entra предоставляют безопасную службу LDAP , которую можно использовать приложениями, которым требуется. Этот параметр отключен по умолчанию. Чтобы включить безопасный протокол LDAP, необходимо загрузить сертификат. Кроме того, группа безопасности сети (NSG), защищающая виртуальную сеть (VNet), на которой развернуты доменные службы Microsoft Entra, должна разрешать подключение к управляемым доменам Microsoft Entra Domain Services через порт 636. Дополнительные сведения см. в разделе "Настройка защищенного LDAP" для управляемого домена доменных служб Microsoft Entra.

Администрирование — Для выполнения обязанностей администрирования в доменных службах Microsoft Entra (например, присоединение машин к домену или изменение групповой политики), учетная запись, используемая для этой задачи, должна быть частью группы администраторов DC Microsoft Entra. Учетные записи, которые являются членами этой группы, не могут напрямую входить на контроллеры домена для выполнения задач управления. Вместо этого вы создадите виртуальную машину управления, присоединенную к управляемому домену доменных служб Microsoft Entra, а затем установите обычные средства управления AD DS. Дополнительные сведения см. в разделе "Основные понятия управления" для учетных записей пользователей, паролей и администрирования в доменных службах Microsoft Entra.

Хэши паролей - Для того чтобы проверка подлинности с использованием доменных служб Microsoft Entra работала, хэши паролей всех пользователей должны быть в формате, подходящем для аутентификации NT LAN Manager (NTLM) и Kerberos. Чтобы убедиться, что проверка подлинности с помощью доменных служб Microsoft Entra работает должным образом, необходимо выполнить следующие предварительные требования.

• Пользователи, синхронизированные с Microsoft Entra Connect (из AD DS) — устаревшие хэши паролей должны быть синхронизированы из локальной службы AD DS с идентификатором Microsoft Entra.

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

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

• Доменные службы Microsoft Entra должны быть развернуты в собственной подсети: не используйте существующую подсеть или подсеть шлюза.

• Группа безопасности сети (NSG) создается во время развертывания управляемого домена доменных служб Microsoft Entra. Эта группа сетевой безопасности содержит необходимые правила для правильного взаимодействия сервисов. Не создавайте и не используйте существующую группу безопасности сети с собственными настраиваемыми правилами.

• Для доменных служб Microsoft Entra требуется 3-5 IP-адресов. Убедитесь, что диапазон IP-адресов подсети может предоставить это количество адресов. Ограничение доступных IP-адресов может запретить доменным службам Microsoft Entra поддерживать два контроллера домена.

• DNS-сервер виртуальной сети - Как уже обсуждалось в контексте модели "концентратор и периферийный", важно правильно настроить DNS на виртуальных сетях, чтобы убедиться, что серверы, присоединенные к управляемому домену Microsoft Entra Domain Services, имеют правильные параметры DNS для разрешения этого домена. Каждая виртуальная сеть имеет запись DNS-сервера, передаваемую серверам по мере получения IP-адреса, и эти записи DNS должны быть IP-адресами управляемого домена доменных служб Microsoft Entra. Дополнительные сведения см. в статье Обновление настроек DNS для виртуальной сети Azure.

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

• Некоторые конфигурации доменных служб Microsoft Entra можно администрировать только с сервера, присоединенного к доменным службам Майкрософт.

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

• Для управления исправлениями и развертываниями программного обеспечения может потребоваться дополнительная инфраструктура. Организациям следует рассмотреть возможность развертывания Управления обновлениями Azure, групповой политики (GPO) или System Center Configuration Manager (SCCM) для управления этими серверами.

Для этой изолированной модели предполагается, что нет подключения к виртуальной сети (VNet), где размещен управляемый домен Microsoft Entra Domain Services, из корпоративной сети клиента и что не настроены доверительные отношения с другими лесами. Необходимо создать сервер типа jumpbox или сервер управления, который будет точкой доступа для управления и администрирования доменными службами Microsoft Entra.

Вход в виртуальные машины в Azure с помощью проверки подлинности Microsoft Entra

Если для развертывания рабочих нагрузок IaaS в Azure требуется изоляция удостоверений, то последний вариант — использовать идентификатор Microsoft Entra для входа на серверы в этом сценарии. Это даёт возможность сделать Microsoft Entra ID сферой идентификации для целей проверки подлинности, и изоляции удостоверений можно добиться, настраивая серверы в соответствующей подписке, которая связана с необходимым клиентом Microsoft Entra. При этом необходимо учитывать следующие факторы.

Поддерживаемые операционные системы: вход в виртуальные машины в Azure с помощью проверки подлинности Microsoft Entra в настоящее время поддерживается в Windows и Linux. Дополнительные сведения о поддерживаемых операционных системах см. в документации по Windows и Linux.

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

Требования к сети. Эти виртуальные машины должны получить доступ к идентификатору Microsoft Entra для проверки подлинности, поэтому необходимо убедиться, что конфигурация сети виртуальных машин разрешает исходящий доступ к конечным точкам Microsoft Entra на 443. Дополнительные сведения см. в документации по Windows и Linux.

Контроль доступа на основе ролей (RBAC). Для предоставления соответствующего уровня доступа к этим виртуальным машинам доступны две роли RBAC. Эти роли RBAC можно настроить с помощью портал Azure или с помощью Интерфейса Azure Cloud Shell. Дополнительные сведения см. в статье Настройка назначений ролей для виртуальной машины.

• Имя для входа администратора виртуальной машины. Пользователи с этой ролью могут входить в виртуальную машину Azure с привилегиями администратора.

• Имя для входа пользователя виртуальной машины. Пользователи с этой ролью могут входить в виртуальную машину Azure с привилегиями обычного пользователя.

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

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

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

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

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

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

• Общие сведения о делегированном администрировании и изолированных средах

• Основы Microsoft Entra

• Изоляция ресурсов у одного клиента

• Изоляция ресурсов в многопользовательской среде

• Рекомендации