Cross-tenant management experiences (Интерфейсы управления для различных клиентов)

В качестве поставщика услуг вы можете использовать Azure Lighthouse для управления ресурсами Azure клиентов из собственного клиента Microsoft Entra. В управляемых таким образом клиентах могут выполняться множество общих задач и служб.

Совет

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

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

Клиент Microsoft Entra — это представление организации. Это выделенный экземпляр идентификатора Microsoft Entra, который организация получает при создании отношений с Корпорацией Майкрософт путем регистрации в Azure, Microsoft 365 или других службах. Каждый клиент Microsoft Entra отличается от других клиентов Microsoft Entra и имеет собственный идентификатор клиента (GUID). Дополнительные сведения см. в разделе "Что такое идентификатор Microsoft Entra?

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

При использовании Azure Lighthouse процесс подключения указывает пользователей в клиенте поставщика услуг, которым назначены роли делегированных подписок и групп ресурсов в клиенте клиента. Затем эти пользователи смогут войти на портал Azure под собственными учетными данными и работать с ресурсами, принадлежащими всем заказчикам, к которым у них есть доступ. Пользователи в управляем арендаторе будут видеть всех этих клиентов на странице Мои клиенты на портале Azure. Они также смогут работать с ресурсами напрямую в контексте подписки соответствующего заказчика либо на портале Azure, либо через API.

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

Diagram showing resources for two customers managed through one service provider tenant.

Поддержка интерфейсов API и средств управления

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

Командлет Get-AzSubscription Azure PowerShell по умолчанию отображает TenantId управляемый клиент. ManagedByTenantIds Атрибуты HomeTenantId для каждой подписки позволяют определить, принадлежит ли возвращаемая подписка управляемому клиенту или управляемому клиенту.

Аналогичным образом команды Azure CLI, такие как az account list , показывают homeTenantId и managedByTenants атрибуты. Если вы не видите эти значения при использовании Azure CLI, попробуйте очистить кэш, выполнив az account clear, а затем — az login --identity.

В REST API Azure команды Subscriptions-Get и Subscriptions-List включают в себя ManagedByTenant.

Примечание.

Помимо сведений об арендаторе, связанных с Azure Lighthouse, арендаторы, представленные этими API, также могут отражать арендаторов партнеров для Azure Databricks или управляемых приложений Azure.

Мы предоставляем также специальные API для выполнения задач Azure Lighthouse. Дополнительные сведения см. в разделе Справочные материалы.

Расширенные службы и сценарии

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

Azure Arc

Служба автоматизации Azure.

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

Azure Backup:

Azure Blueprints:

  • Использование Azure Blueprints для оркестрации развертывания шаблонов ресурсов и других артефактов (требуется дополнительный доступ для подготовки подписки клиента).

Управление затратами + выставление счетов Azure.

  • Из управляющего арендатора партнеры CSP могут просматривать и анализировать стоимость потребления до уплаты налогов (не включая покупки) для клиентов, которые приобрели план Azure, а также управлять ей. Затраты основаны на розничных тарифах и доступе на основе ролей Azure (Azure RBAC), который партнер имеет для подписки клиента. В настоящее время можно просмотреть стоимость потребления по розничным тарифам для подписки каждого отдельного клиента на основе доступа Azure RBAC.

Azure Key Vault.

  • Создание хранилищ ключей в арендаторах клиента.
  • Использование управляемого удостоверения для создания хранилищ ключей в арендаторах клиента.

Служба Azure Kubernetes (AKS).

  • Управление размещенными средами Kubernetes, а также развертывание контейнерных приложений и управление ими в клиентах пользователей.
  • Развертывание кластеров и управление ими в арендаторах клиента.
  • Использование Azure Monitor для контейнеров с целью мониторинга производительности в арендаторах клиента

Миграция Azure.

  • Создание проектов миграции в арендаторе клиента и перенос виртуальных машин.

Azure Monitor.

  • Просмотр оповещений для делегированных подписок с возможностью просмотра и обновления оповещений во всех подписках.
  • Просмотр сведений журнала действий для делегированных подписок.
  • Анализ журналов: запрос данных из удаленных рабочих областей в нескольких арендаторах (обратите внимание, что учетные записи службы автоматизации, используемые для получения доступа к данным из рабочих областей в арендаторах клиента, необходимо создавать в одном арендаторе).
  • Создание, просмотр оповещений и управление ими в клиентах клиентов
  • Создание оповещений в арендаторах клиента, которые инициируют автоматизацию (например, Runbook службы автоматизации Azure или Функции Azure) в управляющем арендаторе через веб-перехватчики.
  • Создание параметров диагностики в рабочих областях, созданных в арендаторах клиента, для отправки журналов ресурсов в рабочие области в управляющем арендаторе.
  • Для рабочих нагрузок SAP отслеживайте метрики решений SAP с помощью агрегированного представления в арендаторах клиента.
  • Для Azure AD B2C перенаправление журналов входа и аудита в различные решения для мониторинга.

Сеть Azure.

Политика Azure.

  • Создание и изменение определений политики в делегированных подписках.
  • Развертывание определений политик и назначений политик в нескольких арендаторах.
  • Назначение пользовательских определений политики в делегированных подписках.
  • Клиенты видят политики, созданные поставщиком услуг, наряду с политиками, которые они создали сами.
  • Может исправлять ошибки deployIfNotExists или изменять назначения в управляемом арендаторе.
  • Обратите внимание, что просмотр сведений о соответствии для несоответствующих ресурсов в арендаторах клиентов в настоящее время не поддерживается.

Azure Resource Graph.

  • См. идентификатор клиента в возвращаемых результатах запроса, позволяющий определить, принадлежит ли подписка управляемому клиенту.

Работоспособность служб Azure.

  • Мониторинг работоспособности ресурсов клиента с помощью службы "Работоспособность ресурсов Azure".
  • Отслеживание работоспособности служб Azure, которые используют клиенты.

Azure Site Recovery:

  • Управление параметрами аварийного восстановления для виртуальных машин Azure в арендаторах клиента (обратите внимание, что учетные записи RunAs нельзя использовать для копирования расширений виртуальных машин).

Виртуальные машины Azure.

  • Использование расширений виртуальных машин для выполнения задач настройки и автоматизации после развертывания виртуальных машин Azure.
  • Использование диагностики загрузки для устранения неполадок с виртуальными машинами Azure.
  • Получение доступа к виртуальным машинам с помощью последовательной консоли.
  • Интеграция виртуальных машин с Azure KeyVault для использования паролей, секретов или криптографических ключей для шифрования дисков с помощью управляемого удостоверения посредством политики, что гарантирует хранение секретов в Key Vault в управляемых арендаторах.
  • Обратите внимание, что нельзя использовать идентификатор Microsoft Entra для удаленного входа на виртуальные машины

Microsoft Defender для облака:

  • Видимость между клиентами
    • Мониторинг соответствия политикам безопасности и обеспечение покрытия безопасности для всех ресурсов клиентов
    • Непрерывный мониторинг соответствия нормативным требованиям для нескольких арендаторов в одном представлении.
    • Мониторинг, рассмотрение и определение приоритетных практических рекомендаций по безопасности с вычислением оценки безопасности.
  • Управление безопасностью между клиентами
    • Управление политиками безопасности.
    • Выполнение действий с ресурсами, которые не соответствуют практическим рекомендациям по безопасности.
    • Сбор и хранение данных, связанных с безопасностью.
  • Межтенантное обнаружение угроз и защита
    • Обнаружение угроз в ресурсах клиентов.
    • Применение дополнительных элементов управления защитой от угроз, таких как JIT-доступ к виртуальной машине.
    • Повышение уровня защиты конфигурации группы безопасности сети с помощью адаптивной защиты сети.
    • Обеспечение работы только тех приложений и процессов на серверах, которые должны использоваться с адаптивными элементами управления приложениями.
    • Мониторинг изменений важных файлов и записей реестра с помощью мониторинга целостности файлов (FIM).
  • Обратите внимание, что всю подписку необходимо делегировать управляющему арендатору. Сценарии Microsoft Defender для облака не поддерживаются с делегированными группами ресурсов.

Microsoft Sentinel:

Запросы в службу поддержки.

Текущие ограничения

При использовании всех сценариев следует учитывать следующие текущие ограничения:

  • Запросы, обрабатываемые службой Azure Resource Manager, можно выполнять с помощью Azure Lighthouse. URI операций для этих запросов начинаются с https://management.azure.com. Однако запросы, которые обрабатываются экземпляром типа ресурса (например, доступ к секретам Key Vault или доступ к данным хранилища), не поддерживаются Azure Lighthouse. URI операций для этих запросов обычно начинаются с адреса, уникального для вашего экземпляра, например https://myaccount.blob.core.windows.net или https://mykeyvault.vault.azure.net/. Это также обычно операции с данными, а не операции управления.
  • Назначения ролей должны использовать встроенные роли Azure. В настоящее Azure Lighthouse поддерживает все встроенные роли, за исключением роли "Владелец" и любых встроенных ролей с разрешением DataActions. Роль "Администратор доступа пользователей" поддерживается только для назначения ролей управляемым удостоверениям. Пользовательские роли и роли классического администратора подписки не поддерживаются. Дополнительные сведения см. в статье "Поддержка ролей для Azure Lighthouse".
  • Для пользователей в управляемом клиенте назначения ролей, сделанные через Azure Lighthouse, не отображаются в разделе контроль доступа (IAM) или с такими инструментами CLI, как az role assignment list. Эти назначения отображаются только в портал Azure в разделе "Делегирование Azure Lighthouse" или через API Azure Lighthouse.
  • Хотя вы можете подключить подписки, использующие Azure Databricks, пользователи в управляемом клиенте не могут запускать рабочие области Azure Databricks в делегированной подписке.
  • Хотя вы можете подключить подписки и группы ресурсов с блокировками ресурсов, эти блокировки не будут препятствовать выполнению действий пользователями в управляющем клиенте. Запретить назначения , которые защищают управляемые системой ресурсы (назначенные системой назначения запрета), такие как созданные управляемыми приложениями Azure или Azure Blueprints, не позволяют пользователям в управляемом клиенте действовать в этих ресурсах. Однако пользователи в клиенте клиента не могут создавать собственные запретные назначения.
  • Делегирование подписок через национальное облако и общедоступное облако Azure или через два отдельных национальных облака не поддерживается.

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