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

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

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

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

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

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

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

Примечание.

Подписка может доверять только одному клиенту Microsoft Entra. Однако каждый клиент может доверять нескольким подпискам и подписки можно перемещать между клиентами.

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

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

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

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

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

Примечание.

До ARM существовала другая модель развертывания под названием Azure Service Manager (ASM) или "классическая модель". Дополнительные сведения см. в статье Azure Resource Manager и классическое развертывание. Управление средами с помощью модели ASM выходит за рамки этого материала.

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

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

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

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

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

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

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

Подписки, обеспечивающие делегированное управление ресурсами с помощью 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 и классическое развертывание.)

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

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

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

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

Клиентское соглашение Майкрософт

Клиенты, зарегистрированные в Клиентское соглашение Майкрософт (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 управление привилегированными пользователями, чтобы включить политики JIT-активации, такие как рабочий процесс утверждения и 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 Resource Manager

• Azure PowerShell

• Azure CLI

• Портал Azure

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

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

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

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

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

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

На внутреннем уровне управляемые удостоверения — это субъекты-службы особого типа, которые могут использовать только определенные ресурсы Azure. При удалении управляемого удостоверения соответствующий субъект-служба автоматически удаляется. Теперь авторизация разрешений API Graph может выполняться только с помощью PowerShell, поэтому не все функции управляемого удостоверения доступны с помощью пользовательского интерфейса Portal.

Доменные службы 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, должен иметь разрешения участника или владельца в подписке. После создания этот пользователь становится первым глобальным администратором клиента Azure AD B2C, а затем может создать другие учетные записи и назначить их ролям каталогов.

Важно отметить, что владельцы и участники связанной подписки 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 (потенциально используя те же учетные данные, если вы синхронизировали правильные учетные записи), и это может привести к проверке подлинности на контроллерах домена, если вы используете службы федерации Active Directory (AD FS) (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 — все серверы (за исключением серверов jumpbox), которым для проверки подлинности, настройки и управления требуются 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 доступа к подключению, управлению и настройке виртуальных машин, виртуальных сетей, групп безопасности сети и других необходимых ресурсов Azure.

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

При первом развертывании доменных служб Microsoft Entra автоматическая односторонняя синхронизация настраивается для репликации объектов из идентификатора Microsoft Entra. Эта односторонняя синхронизация продолжает выполняться в фоновом режиме, чтобы обеспечить актуальность управляемого домена доменных служб Microsoft Entra с любыми изменениями с идентификатора Microsoft Entra. Синхронизация не выполняется из доменных служб 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 необходимо отправить сертификат, кроме того, группа безопасности сети, которая защищает виртуальную сеть, на которую развернуты доменные службы Microsoft Entra, чтобы разрешить подключение через порт 636 к управляемым доменам доменных служб Microsoft Entra. Дополнительные сведения см. в разделе "Настройка защищенного LDAP" для управляемого домена доменных служб Microsoft Entra.

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

• Основы Microsoft Entra

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

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

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