Реализация межтенантного взаимодействия с помощью мультитенантных приложений
В этом руководстве представлено решение для обеспечения двунаправленного безопасного взаимодействия между службами, размещенными в подписках Azure, которыми управляют разные клиенты Microsoft Entra.
Защита мультитенантных коммуникаций в Azure может быть сложной из-за ограничений, которые присущи многим службам. Вы можете исключить необходимость управления учетными данными непосредственно с помощью управляемых удостоверений Azure для получения маркеров из идентификатора Microsoft Entra. Однако управляемые удостоверения Azure не работают по границам клиента, и типичным вариантом является использование общих секретов, таких как URL-адреса подписи общего доступа. Помните, что если вы используете общие секреты, необходимо безопасно распространять и менять секреты по границам клиента Microsoft Entra.
Один из вариантов, которые позволяют избежать этой нагрузки, заключается в создании мультитенантного приложения для представления удостоверения рабочей нагрузки. С помощью процесса согласия можно сделать это удостоверение рабочей нагрузки известным внешним клиентом и в конечном итоге позволить ему проходить проверку подлинности служб во внешнем клиенте.
В этой статье представлен пример реализации этого шаблона, использующего пример кода.
Этот шаблон можно повторно использовать для любого мультитенантного сценария с различными службами, которые должны взаимодействовать между границами клиента Microsoft Entra.
Архитектура
Скачайте файл PowerPoint этой архитектуры.
Рабочий процесс
Следующий рабочий процесс соответствует предыдущей схеме:
Администратор на стороне поставщика создает мультитенантную регистрацию приложений и настраивает секрет клиента для него.
Администратор на стороне клиента подготавливает субъект-службу в клиенте. Этот субъект-служба основан на мультитенантном приложении, созданном поставщиком. Этот шаг можно выполнить несколькими способами. В этом примере мы решили создать URL-адрес для предоставления администратору клиента, но вместо этого можно использовать API Microsoft Graph.
Клиент применяет роли управления доступом на основе ролей (RBAC) к этому новому субъекту-службе, чтобы он был авторизован для доступа к Служебная шина Azure.
Приложение-функция поставщика использует идентификатор клиента и секрет клиента регистрации приложения для отправки аутентифицированного сообщения в очередь служебная шина клиента.
Приложение-функция клиента использует управляемое удостоверение для чтения сообщения поставщика из очереди с помощью триггера служебная шина.
После получения сообщения приложение-функция клиента обычно выполняет некоторые действия перед отправкой сообщения о состоянии поставщику. В этом случае для демонстрационных целей приложение-функция немедленно отправляет поставщику сообщение о состоянии в отдельной очереди в той же служебная шина.
Это приложение-функция считывает из очереди состояния клиента через таймер, который Функции Azure триггеров.
Подробности сценария
У поставщика несколько клиентов. Поставщик и каждый клиент имеют собственный отдельный клиент Microsoft Entra ID и ресурсы Azure. Поставщик и каждый клиент нуждаются в безопасном двунаправленном методе связи, чтобы они могли обмениваться сообщениями с помощью очередей служебная шина. Решение должно иметь убедительные истории идентификации, которая не позволяет вводить ненужные учетные данные или секреты.
Что знать о мультитенантных приложениях
Объект приложения — это глобальный уникальный экземпляр приложения.
Когда приложение зарегистрировано в Microsoft Entra, объект приложения и объект субъекта-службы автоматически создаются в клиенте.
Объект субъекта-службы создается в каждом клиенте, который использует приложение и ссылается на объект приложения. Объект приложения имеет связь "один ко многим" с соответствующим объектом субъекта-службы.
Объект приложения — это глобальное представление приложения и используется во всех клиентах. Объект субъекта-службы — это локальное представление, используемое в определенном клиенте.
Объект субъекта-службы должен быть создан в каждом клиенте, где используется приложение, чтобы установить удостоверение для доступа к ресурсам, защищенным клиентом. Однотенантное приложение имеет только один объект субъекта-службы в своем домашнем клиенте. Этот объект субъекта-службы создается и разрешено для использования во время регистрации приложения. Мультитенантное приложение также имеет объект субъекта-службы, созданный в каждом клиенте, и пользователь из этого клиента согласился на его использование.
Чтобы получить доступ к ресурсам, защищенным клиентом Microsoft Entra, субъект безопасности должен представлять сущность, требующую доступа.
Когда приложению предоставлено разрешение на доступ к ресурсам в клиенте при регистрации или согласии, создается объект субъекта-службы. Эта архитектура реализуется с потоком согласия.
Как поставщик сообщения клиенту?
В идеале поставщик может назначить управляемое удостоверение вычислительному ресурсу Azure, ответственному за отправку сообщений в очередь клиента. Клиент клиента настроен для доверия управляемым удостоверениям из клиента поставщика. Однако истинная федерация между двумя клиентами Microsoft Entra, которая, по сути, позволит "совместное использование" удостоверений из одного клиента в другой, в настоящее время невозможно. Таким образом, поставщику необходимо пройти проверку подлинности с помощью удостоверения, распознаваемого клиентом. Поставщик должен пройти проверку подлинности в клиенте Microsoft Entra клиента в качестве субъекта-службы, о чем знает клиент.
Мы рекомендуем поставщику зарегистрировать мультитенантное приложение в собственном клиенте, а затем подготовить каждого клиента связанного субъекта-службы в клиенте. Затем поставщик может пройти проверку подлинности в клиенте клиента и размещенных клиентом API с помощью этого субъекта-службы. Поставщик никогда не должен предоставлять общий доступ к секрету клиента в этом подходе. Управление учетными данными является единственной ответственностью поставщика.
Как клиент выводит сообщение поставщику?
Мы рекомендуем клиенту создавать или размещать очередь, из которой поставщик может считывать. Клиент записывает сообщение в очередь. Поставщик неоднократно опрашивает каждую очередь клиента для сообщений с помощью объекта субъекта-службы. Недостатком этого подхода является то, что он вводит задержку опроса, когда поставщик получает сообщение. Код также должен выполняться чаще в поставщике, так как он должен проснуться и выполнить логику опроса, а не ожидать активации события. Однако управление учетными данными остается единственной ответственностью поставщика, что повышает безопасность.
Другим возможным решением является создание или размещение очереди поставщика для каждого из своих клиентов. Каждый клиент создает собственное мультитенантное приложение и запрашивает, что поставщик подготавливает его в клиенте в качестве объекта субъекта-службы. Затем клиент использует этот объект субъекта-службы для отправки сообщений в очередь конкретного клиента на стороне поставщика. Управление учетными данными остается единственной ответственностью клиента. Одним из недостатков этого подхода является то, что поставщик должен подготавливать субъекты-службы, связанные с клиентскими приложениями в клиенте. Этот процесс выполняется вручную, и поставщики, скорее всего, не хотят, чтобы шаги вручную были частью потока для подключения нового клиента.
Пример установки кода
Ниже приведены инструкции по настройке межтенантного взаимодействия между поставщиком и клиентом.
Настройка поставщика
Настройка поставщика включает шаги по созданию и подготовке мультитенантного субъекта-службы приложений и шагов по подготовке клиента.
Создайте приложение-функцию с триггером HTTP, чтобы отправить сообщение для записи в очередь команд клиента служебная шина в клиенте.
Создайте приложение-функцию с активацией по времени, чтобы периодически проверять очередь состояния в служебная шина клиента в клиенте.
Создание мультитенантного приложения в клиенте поставщика
Сначала создайте мультитенантное приложение в клиенте поставщика и подготовьте это удостоверение в клиенте клиента. В этом сценарии удостоверение является субъектом-службой. Архитектура, описанная ранее в этой статье, показывает, как настроить и подготовить субъект-службу из клиента поставщика в клиент клиента. Архитектура также описывает подготовку нескольких клиентов Microsoft Entra.
Выберите параметр мультитенантной организации.
Добавьте следующий веб-сайт в качестве URI перенаправления:
https://entra.microsoft.comЭтот универсальный код ресурса (URI) можно изменить в соответствии с потребностями бизнеса.Зарегистрируйте и запишите значение идентификатора приложения (клиента).
Создание секрета клиента
После создания мультитенантного приложения создайте секрет клиента для этого субъекта-службы.
Сохраните созданный секрет в безопасном расположении. Секрет и идентификатор клиента — это учетные данные клиента, необходимые для обмена кодом в потоке кода авторизации и маркера идентификатора на следующем шаге.
Функции Azure — http-триггер
Используйте функцию HTTP для запуска развертывания из клиента поставщика, отправив сообщение в очередь развертывания служебная шина клиента. Мы выбрали функцию, активируемую HTTP, в качестве метода доставки для запуска этой проверки концепции. Субъект-служба, созданный ранее, выступает в качестве учетных данных для доступа к клиенту клиента и записи в определенную очередь в служебная шина. Вам также необходимо завершить настройку клиента для правильной работы этого шага.
Функции Azure — триггер таймера
Используйте функцию, активированную таймером, для опроса очереди состояния развертывания из клиента. Мы опрашим очередь состояния развертывания каждые 10 секунд для демонстрационных целей в этой проверке концепции. Этот подход устраняет необходимость для клиента иметь субъект-службу для доступа к клиенту поставщика.
Настройка клиента
Подготовьте субъект-службу, изменив и используя предоставленный URL-адрес.
Область действия субъекта-службы поставщика для использования соответствующих элементов управления RBAC.
Создайте функцию, активированную служебная шина, чтобы прочитать сообщение из очереди сообщений служебная шина и поместить сообщение в другую очередь. Для демонстрационных целей этот поток является оптимальным для тестирования функциональных возможностей.
Создайте управляемое удостоверение, назначаемое системой, для служебная шина активированной функции.
Назначьте управляемое удостоверение, назначаемое системой, служебная шина области.
Подготовка субъекта-службы от клиента поставщика к клиенту клиента
Перейдите по следующему 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 — триггер служебная шина
Выполните действия, описанные в руководстве по функциям на основе удостоверений, чтобы определить триггер функции из очереди служебная шина и узнать, как настроить управляемое удостоверение. Это руководство помогает активировать приложение-функцию из очереди служебная шина при добавлении сообщения в очередь. Вы также используете управляемое удостоверение при помещении сообщения в другую очередь. Для демонстрационных целей мы используем ту же функцию для отправки сообщения.
В созданном пространстве имен служебная шина выберите контроль доступа (IAM). Вы можете просмотреть и настроить доступ к ресурсу в плоскости управления.
Предоставление приложению-функции доступа к пространству имен служебная шина с помощью управляемых удостоверений
Убедитесь, что вы добавите роль "приемник данных Служебная шина Azure" в управляемое удостоверение.
В селекторе управляемых удостоверений выберите приложение-функцию из категории управляемых удостоверений, назначаемой системой. Приложение-функция метки может иметь число в скобках рядом с ним. Это число указывает, сколько приложений с удостоверениями, назначенными системой, находятся в подписке.
Подключение к Служебной шине в приложении-функции
На портале найдите приложение-функцию или перейдите к нему на странице приложения-функции .
В параметрах приложения выберите +Создать , чтобы создать новый параметр приложения в таблице.
Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.
Управление жизненным циклом секрета клиента субъекта-службы
Если вы вводите секреты в архитектуру кросстенантного клиента, необходимо управлять жизненным циклом созданных секретов клиента. Ознакомьтесь с рекомендациями по управлению секретами, чтобы узнать, как безопасно хранить, поворачивать и отслеживать секреты клиентов.
Локальные параметры
Каждая подкаталога содержит ступеную версию файлов, которую можно изменить для локального local.settings.json запуска функций Azure. Чтобы настроить параметры в Azure, обновите параметры приложения.
Команда DefaultAzureCredential перечисляет несколько параметров до достижения учетных данных Azure CLI. Чтобы избежать путаницы, рекомендуется выполнить az login -t <tenant ID> команду, чтобы выбрать правильные учетные данные при разработке локальных функций.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Основные авторы:
- Одри Лонг | Старший инженер по обеспечению безопасности
- Эштон Микки | Главный инженер программного обеспечения
- Джон Гарленд | Главный инженер программного обеспечения
Следующие шаги
- Обмен данными между клиентами с помощью примера кода Служебная шина Azure
- Руководство по функциям на основе удостоверений