Арендаторы, роли и пользователи в сценариях Azure Lighthouse

  • Статья

Прежде чем подключить клиентов для Azure Lighthouse, важно понять, как клиенты Microsoft Entra, пользователи и роли работают, а также как их можно использовать в сценариях Azure Lighthouse.

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

Для обеспечения этой логической проекции подписка (либо одна или несколько групп ресурсов в подписке) в арендаторе клиента должна быть подключена к Azure Lighthouse. Этот процесс подключения можно выполнить либо с помощью шаблонов Azure Resource Manager, либо посредством публикации общедоступного или частного предложения в Azure Marketplace.

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

Примечание.

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

Рекомендации по определению пользователей и ролей

При создании авторизаций рекомендуется следующее.

  • В большинстве случаев вы хотите назначить разрешения группе пользователей Или субъекту-службе Microsoft Entra, а не серии отдельных учетных записей пользователей. Это позволяет добавлять или удалять доступ для отдельных пользователей с помощью идентификатора Microsoft Entra клиента, а не обновлять делегирование при каждом изменении требований к индивидуальному доступу.
  • Следуйте принципу предоставления минимальных прав, чтобы у пользователей были только разрешения, необходимые для выполнения их заданий. Это помогает снизить вероятность непреднамеренных ошибок. Дополнительные сведения см. в статье Рекомендации по безопасности.
  • Добавьте авторизацию с ролью для удаления назначения регистрации управляемых служб, чтобы позже можно было при необходимости удалить доступ к делегированию. Если эта роль не назначена, доступ к делегированным ресурсам можно удалить только пользователем в клиенте клиента.
  • Убедитесь, что любой пользователь, который должен просмотреть страницу "Мои клиенты" в портал Azure имеет роль читателя (или другую встроенную роль, которая включает доступ читателя).

Важно!

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

Поддержка ролей для Azure Lighthouse

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

Все встроенные роли в настоящее время поддерживаются в Azure Lighthouse, за исключением следующих:

  • Роль Владелец не поддерживается.

  • Роль пользователя Администратор istrator поддерживается, но только для ограниченной цели назначения ролей управляемому удостоверению в клиенте клиента. Никакие другие разрешения, обычно предоставляемые этой ролью, применяться не будут. Если вы определяете пользователя с этой ролью, необходимо также указать роли, которые этот пользователь может назначить управляемым удостоверениям.

  • Все роли с DataActions разрешениями не поддерживаются.

  • Роли, включающие какие-либо из следующих действий , не поддерживаются:

    • */Написать
    • */delete
    • Microsoft.Authorization/*
    • Microsoft.Authorization/*/write
    • Microsoft.Authorization/*/delete
    • Microsoft.Authorization/roleAssignments/write.
    • Microsoft.Authorization/roleAssignments/delete
    • Microsoft.Authorization/roleDefinitions/write
    • Microsoft.Authorization/roleDefinitions/delete
    • Microsoft.Authorization/classicAdministrators/write
    • Microsoft.Authorization/classicAdministrators/delete
    • Microsoft.Authorization/locks/write
    • Microsoft.Authorization/locks/delete
    • Microsoft.Authorization/denyAssignments/write
    • Microsoft.Authorization/denyAssignments/delete

Важно!

При назначении ролей обязательно просмотрите действия , указанные для каждой роли. В некоторых случаях, даже если роли с DataActions разрешениями не поддерживаются, действия, включенные в роль, могут разрешить доступ к данным, где данные предоставляются с помощью ключей доступа и не получают доступ через удостоверение пользователя. Например, роль участника виртуальной машины включает Microsoft.Storage/storageAccounts/listKeys/action действие, которое возвращает ключи доступа к учетной записи хранения, которые можно использовать для получения определенных данных клиента.

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

После добавления новой встроенной роли в Azure ее можно назначить при подключении клиента с помощью шаблонов Azure Resource Manager. При публикации предложения управляемой службы может возникнуть задержка до того, как новая добавленная роль станет доступной в Центре партнеров. Аналогичным образом, если роль становится недоступной, вы все равно увидите ее в Центре партнеров в течение некоторого времени; Однако вы не сможете публиковать новые предложения с помощью таких ролей.

Передача делегированных подписок между клиентами Microsoft Entra

Если подписка передается в другую учетную запись клиента Microsoft Entra, сохраняются ресурсы определения регистрации и назначения регистрации, созданные с помощью процесса подключения Azure Lighthouse. Это означает, что доступ, предоставленный через Azure Lighthouse для управления клиентами, остается в силе для этой подписки (или для делегированных групп ресурсов в этой подписке).

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

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