Реализация обмена данными между каталогами в Azure
В этом руководстве представлено решение для обеспечения двунаправленного безопасного взаимодействия между службами, размещенными в подписках Azure, которые управляют различными каталогами Microsoft Entra.
Защита обмена данными между каталогами в Azure может быть сложной из-за ограничений, которые присущи многим службам. Вы можете исключить необходимость управления учетными данными непосредственно с помощью управляемых удостоверений Azure для получения маркеров из идентификатора Microsoft Entra. Однако управляемые удостоверения Azure не работают за пределами каталогов, а типичным вариантом является использование общих секретов, таких как URL-адреса подписи общего доступа. Помните, что если вы используете общие секреты, их необходимо безопасно распространять и обновлять в пределах границ каталога Microsoft Entra.
Один из вариантов, которые позволяют избежать этой нагрузки, заключается в создании мультитенантного приложения Microsoft Entra для идентификации рабочей нагрузки. С помощью процесса согласия можно представить это удостоверение рабочей нагрузки внешнему каталогу и в конечном итоге позволить приложению аутентифицировать службы во внешнем каталоге.
В этой статье представлен пример реализации этого шаблона, использующего пример кода.
Этот шаблон можно повторно использовать для любого сценария с различными службами, которые должны взаимодействовать между границами каталога Microsoft Entra.
Архитектура
Скачайте файл PowerPoint этой архитектуры.
Рабочий процесс
Следующий рабочий процесс соответствует предыдущей схеме:
Администратор на стороне поставщика создает регистрацию мультитенантного приложения Entra и настраивает секрет клиента для него.
Администратор на стороне клиента создает учетную запись службы в каталоге Microsoft Entra. Этот субъект-служба основан на регистрации приложения, созданной поставщиком. Этот шаг можно выполнить несколькими способами. В этом примере мы решили создать URL-адрес для предоставления администратору каталога клиента, но вместо этого можно использовать API Microsoft Graph.
Клиент применяет роли управления доступом на основе ролей (RBAC) к этому новому субъекту-службе, чтобы он был авторизован для доступа к Служебная шина Azure.
Приложение-функция поставщика использует идентификатор клиента и секрет клиента регистрации приложения для отправки аутентифицированного сообщения в очередь служебная шина клиента.
Приложение-функция клиента использует управляемое удостоверение для чтения сообщения поставщика из очереди с помощью триггера служебная шина.
После получения сообщения приложение-функция клиента обычно выполняет некоторые действия перед отправкой сообщения о состоянии поставщику. В этом случае для демонстрационных целей приложение-функция немедленно отправляет поставщику сообщение о состоянии в отдельной очереди в той же служебная шина.
Это приложение читает из очереди статусов в каталоге клиента согласно таймеру, запускаемому 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.
Создайте функцию, активированную служебная шина, чтобы прочитать сообщение из очереди сообщений служебная шина и поместить сообщение в другую очередь. Для демонстрационных целей этот поток является оптимальным для тестирования функциональных возможностей.
Создайте управляемое удостоверение, назначаемое системой, для служебная шина активированной функции.
Назначьте управляемое удостоверение, назначаемое системой, служебная шина области.
Подготовка учетной записи службы в каталоге поставщика для каталога клиента
Перейдите по следующему 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
- Руководство по функциям на основе удостоверений