Поделиться через

Арендаторы, роли и пользователи в сценариях 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, за исключением следующих:

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

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

  • Все роли с 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). Однако если эта подписка была делегирована другим клиентам управления, другие управляющие клиенты будут сохранять тот же доступ к подписке.

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