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

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

Это важно

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

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

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

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

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

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

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

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

    • Microsoft.Authorization/*
    • Microsoft.Authorization/*/write
    • Microsoft.Authorization/*/удаление
    • Microsoft.Authorization/roleAssignments/write (Microsoft.Authorization/назначенияРолей/запись)
    • 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). Однако если эта подписка была делегирована другим клиентам управления, другие управляющие клиенты будут сохранять тот же доступ к подписке.

Дальнейшие шаги