Реализация обмена данными между каталогами в Azure

2025-04-17

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

Защита обмена данными между каталогами в Azure может быть сложной из-за ограничений, которые присущи многим службам. Вы можете исключить необходимость непосредственного управления учетными данными, используя управляемые удостоверения Azure для получения токенов от Entra ID от Microsoft. Однако управляемые удостоверения Azure не работают за пределами каталогов, а типичным вариантом является использование общих секретов, таких как URL-адреса подписи общего доступа. Помните, что если вы используете общие секреты, их необходимо безопасно распространять и обновлять в пределах границ каталога Microsoft Entra.

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

В этой статье представлен пример реализации этого шаблона, использующего пример кода.

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

Архитектура

Скачайте файл PowerPoint этой архитектуры.

Рабочий процесс

Следующий рабочий процесс соответствует предыдущей схеме:

Администратор на стороне поставщика создает регистрацию мультитенантного приложения Entra и настраивает секрет клиента для него.
Администратор на стороне клиента создает учетную запись службы в каталоге Microsoft Entra. Этот субъект-служба основан на регистрации приложения, созданной поставщиком. Этот шаг можно выполнить несколькими способами. В этом примере мы решили создать URL-адрес для предоставления администратору каталога клиента, но вместо этого можно использовать API Microsoft Graph.
Клиент применяет роли управления доступом на основе ролей (RBAC) к этой новой учетной записи службы, чтобы авторизовать ее для доступа к Службе шины Azure.
Приложение-функция поставщика использует идентификатор клиента и секретный ключ клиента из регистрации приложения для отправки аутентифицированного сообщения в очередь шины Service Bus клиента.
Функциональное приложение клиента использует управляемое удостоверение для чтения сообщения поставщика из очереди с помощью триггера Service Bus.
После получения сообщения приложение-функция клиента обычно выполняет некоторые действия перед отправкой сообщения о состоянии поставщику. В этом случае для демонстрационных целей приложение-функция немедленно отправляет поставщику сообщение о состоянии в отдельной очереди в той же служебная шина.
Это приложение читает из очереди статусов в каталоге клиента согласно таймеру, запускаемому Azure Functions.

Подробности сценария

У поставщика несколько клиентов. У поставщика и каждого клиента есть собственный отдельный каталог идентификатора Microsoft Entra и ресурсы Azure. Поставщик и каждый клиент нуждаются в безопасном двунаправленном методе связи, чтобы они могли обмениваться сообщениями с помощью очередей служебная шина. Решение должно иметь убедительные истории идентификации, которая не позволяет вводить ненужные учетные данные или секреты.

Что нужно знать о многопользовательских приложениях Entra

Объект приложения — это глобальный уникальный экземпляр приложения.
Когда приложение регистрируется в Microsoft Entra, в каталоге автоматически создаются объект приложения и объект служебного принципала.
Объект principal службы создается в каждом каталоге, который использует приложение и ссылается на объект приложения. Объект приложения имеет связь "один ко многим" с соответствующим объектом сервисного принципала.
Объект приложения — это глобальное представление приложения и используется во всех каталогах. Объект сервисного принципала — это локальное представление, используемое в конкретном каталоге.
Объект основного сервисного объекта должен быть создан в каждом каталоге, где используется приложение, для установления идентификации, необходимой для доступа к ресурсам, которые защищены этим каталогом. Приложение с одним каталогом имеет только один объект основного субъекта службы в домашнем каталоге. Этот служебный объект создается и предназначен для использования во время регистрации приложения. Многотенантное приложение Entra также имеет объект "служебного принципала", созданный в каждом каталоге, причем пользователь из этого каталога дал согласие на его использование.
Чтобы получить доступ к ресурсам, защищенным каталогом Microsoft Entra, субъект безопасности должен представлять сущность, требующую доступа.
Когда приложению предоставлено разрешение на доступ к ресурсам в каталоге в момент регистрации или предоставления согласия, создается объект служебного субъекта. Эта архитектура реализуется через процесс согласования.

Каким образом поставщик отправляет сообщения клиенту?

В идеале поставщик может назначить управляемое удостоверение вычислительному ресурсу Azure, отвечающему за отправку сообщений в очередь клиента. Каталог клиента настроен так, чтобы доверять управляемым удостоверениям из каталога поставщика. Однако истинная федерация между двумя арендаторами Microsoft Entra, что, по сути, позволило бы "совместное использование" удостоверений из одного каталога в другой, в настоящее время невозможна. Таким образом, поставщику необходимо пройти проверку подлинности с помощью удостоверения, распознаваемого клиентом. Поставщик должен пройти проверку подлинности в Microsoft Entra клиента в качестве учетной записи службы, о которой клиент знает.

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

Как клиент выводит сообщение поставщику?

Мы рекомендуем клиенту создавать или размещать очередь, из которой поставщик может считывать. Клиент записывает сообщение в очередь. Поставщик неоднократно опрашивает каждую очередь клиента для сообщений с помощью объекта субъекта-службы. Недостатком этого подхода является то, что он вводит задержку опроса, когда поставщик получает сообщение. Код также должен выполняться чаще в поставщике, так как он должен проснуться и выполнить логику опроса, а не ожидать активации события. Однако управление учетными данными остается единственной ответственностью поставщика, что повышает безопасность.

Другим возможным решением является создать отдельную очередь для каждого клиента или разместить её через поставщика. Каждый клиент создает собственное многопользовательское приложение Entra и запрашивает у поставщика его развертывание в каталоге в виде объекта основного сервиса. Затем клиент использует этот объект служебного принципала для отправки сообщений в очередь, специфичную для клиента, на стороне провайдера. Управление учетными данными остается единственной ответственностью клиента. Одним из недостатков этого подхода является то, что поставщик должен готовить учетные записи служб, связанные с клиентскими приложениями, в своем каталоге. Этот процесс выполняется вручную, и поставщики, скорее всего, не хотят, чтобы шаги вручную были частью потока для подключения нового клиента.

Пример установки кода

Ниже приведены инструкции по настройке обмена данными между поставщиком и клиентом.

Настройка поставщика

Настройка поставщика включает шаги по созданию и развертыванию мультитенантного основного объекта службы приложения Entra, а также шаги по развертыванию каталога клиента.

Создайте функциональное приложение с HTTP-триггером, чтобы отправить сообщение для записи в командную очередь Service Bus в каталоге клиента.
Создайте приложение-функцию с запуском по времени для периодической проверки очереди статуса в служебной шине клиента внутри его каталога.

Создайте мультитенантное приложение Entra в каталоге поставщика

Сначала создайте мультитенантное приложение Entra в каталоге поставщика и предоставьте это удостоверение в каталоге клиента. В этом сценарии удостоверение является учетной записью службы. В архитектуре , описанной ранее в этой статье, показано, как настроить и подготовить учетную запись службы из каталога поставщика в каталог клиента. Архитектура также описывает, как обеспечить конфигурирование нескольких клиентов Microsoft Entra.

Выберите опцию многопользовательской организации.
Добавьте следующий веб-сайт в качестве URI перенаправления: https://entra.microsoft.com Этот универсальный код ресурса (URI) можно изменить в соответствии с потребностями бизнеса.
Зарегистрируйте и запишите значение идентификатора приложения (клиента).

Создание секрета клиента

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

Функции Azure — HTTP-триггер

Используйте функцию HTTP для запуска развертывания из каталога поставщика, отправив сообщение в очередь развертывания служебной шины клиента. Мы выбрали функцию, активируемую HTTP, в качестве метода доставки для запуска этой проверки концепции. Принципал службы, созданный ранее, выступает в качестве учетной записи для доступа к директории клиента и записи в определенную очередь в Service Bus. Вам также необходимо завершить настройку клиента для правильной работы этого шага.

Функции Azure — запуск на основе таймера

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

Настройка клиента

Настройте учетную запись службы, измените и используйте предоставленный URL-адрес.
Определите область применения учетной записи службы поставщика для использования соответствующего управления доступом на основе ролей (RBAC).
Создайте функцию, активированную служебная шина, чтобы прочитать сообщение из очереди сообщений служебная шина и поместить сообщение в другую очередь. Для демонстрационных целей этот поток является оптимальным для тестирования функциональных возможностей.
Создайте управляемую удостоверение, назначаемую системой, для функции, активируемой Service Bus.
Назначьте управляемое удостоверение, назначаемое системой, служебная шина области.

Подготовка учетной записи службы в каталоге поставщика для каталога клиента

Перейдите по следующему URL-адресу после замены client_id параметра строки запроса собственным идентификатором клиента: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>

Вы также можете подготовить субъект-службу в другой клиент Microsoft Entra с вызовом API Microsoft Graph администратора, командой Azure PowerShell или командой Azure CLI.
Войдите с помощью учетной записи из директории клиента.
На экране согласия выберите Принять, чтобы выполнить настройку приложения поставщика в директории клиента. URL-адрес в конечном итоге перенаправляется на microsoft.com, который всё ещё оказывает требуемое действие для записи удостоверения в каталог клиента.
Проверьте удостоверение в Microsoft Entra клиента, перейдя в Общие приложения, чтобы просмотреть только что подготовленную учетную запись службы.

Настройка RBAC для подготовленного субъекта-службы

Назначьте субъекту-службы поставщика из настройки роли "Владелец данных в служебной шине" для использования на служебной шине. Этот служебный принципал используется как при записи в очередь с HTTP-триггерной функцией, так и для чтения из очереди с функцией таймера. Убедитесь, что вы добавили роль "владелец данных Служебной шины Azure" для служебного принципала.

Функции Azure — триггер Service Bus

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

В новом пространстве имен службы шины выберите Контроль доступа (IAM). Вы можете просмотреть и настроить доступ к ресурсу в плоскости управления.

Предоставить функциональному приложению доступ к пространству имен Service Bus с помощью управляемых удостоверений.

Убедитесь, что вы добавили роль «Приемник данных службы Azure Service Bus» в управляемое удостоверение.
В селекторе управляемых удостоверений выберите Приложение функций из категории назначенное системой управляемое удостоверение. Метка Function App может иметь число в скобках рядом с ней. Это число указывает, сколько приложений с системно назначенными идентификаторами находятся в подписке.

Подключение к Service Bus в функциональном приложении

На портале найдите своё функциональное приложение или перейдите к нему на странице функционального приложения.
В параметрах приложения выберите +Создать , чтобы создать новый параметр приложения в таблице. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Управление жизненным циклом ключа учетной записи службы

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

Локальные параметры

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

Команда DefaultAzureCredential перечисляет несколько параметров, прежде чем получить учетные данные Azure CLI. Чтобы избежать путаницы, рекомендуется выполнить az login -t <tenant ID> команду, чтобы выбрать правильные учетные данные при разработке локальных функций.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

Одри Лонг | Старший инженер по обеспечению безопасности
Эштон Микки | Главный инженер программного обеспечения
Джон Гарленд | Главный инженер программного обеспечения