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

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

Тенант — это выделенный и доверенный экземпляр Microsoft Entra ID. Как правило, каждый клиент представляет отдельную организацию. Azure Lighthouse включает логическую проекцию ресурсов от одного клиента к другому клиенту. Пользователи в клиенте-менеджере, например, тот, который принадлежит поставщику услуг, могут получить доступ к делегированным ресурсам в клиентском клиенте. Enterprises с несколькими арендаторами также могут использовать Azure Lighthouse для централизации операций управления.

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

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

Замечание

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

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

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

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

Это важно

Чтобы добавить разрешения для группы Microsoft Entra, задайте для типа Group значение Security. Этот параметр выбирается при создании группы.

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

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

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

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

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

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

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

    • Майкрософт. Авторизации/*
    • Майкрософт. Авторизация/*/запись
    • Майкрософт. Авторизация/*/delete
    • Майкрософт. Authorization/roleAssignments/write
    • Майкрософт.Authorization/roleAssignments/delete
    • Майкрософт. Authorization/roleDefinitions/write
    • Майкрософт.Authorization/roleDefinitions/delete
    • Майкрософт. Authorization/classicAdministrators/write
    • Майкрософт.Authorization/classicAdministrators/delete
    • Майкрософт. Авторизация, блокировка и запись
    • Майкрософт. Авторизация, блокировка и удаление
    • Майкрософт. Авторизация/denyAssignments/write
    • Майкрософт. Authorization/denyAssignments/delete

Это важно

При назначении ролей просмотрите действия , указанные для каждой роли. Несмотря на то, что Azure Lighthouse не поддерживает роли с разрешением DataActions, некоторые действия, включенные в поддерживаемую роль, могут разрешить доступ к данным. Этот доступ обычно возникает, когда данные предоставляются с помощью ключей доступа, а не через удостоверение пользователя. Например, роль Виртуальная машина Соучастник включает действие Майкрософт.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. Однако если вы также делегировали эту подписку другим управляющим арендаторам, они сохраняют доступ к подписке в том же объеме.

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

  • Last updated on