Поделиться через

Платформа модели безопасных приложений

  • Статья

Корпорация Майкрософт вводит безопасную масштабируемую платформу для проверки подлинности партнеров поставщика облачных решений (CSP) и поставщиков панелей управления (CPV) с помощью архитектуры многофакторной проверки подлинности (MFA) Microsoft Azure. Партнеры CSP и поставщики панели управления могут полагаться на новую модель для повышения безопасности вызовов интеграции API Центра партнеров. Это помогает всем сторонам, включая партнеров Майкрософт, CSP и поставщиков панели управления, защищать свою инфраструктуру и данные клиентов от рисков безопасности.

Важный

Azure Active Directory (Azure AD) Graph не рекомендуется использовать с 30 июня 2023 г. В дальнейшем мы не будем делать дополнительных инвестиций в Azure AD Graph. API Graph Azure AD не имеют обязательств по SLA или обслуживанию, кроме исправлений, связанных с безопасностью. Инвестиции в новые функции и функциональные возможности будут сделаны только в Microsoft Graph.

Мы постепенно выведем из эксплуатации Azure AD Graph, чтобы у вас было достаточно времени для миграции приложений на API Microsoft Graph. На более позднюю дату, которую мы объявим, мы заблокируем создание новых приложений с помощью Azure AD Graph.

Дополнительные сведения см. в статье Важно: прекращение использования Azure AD Graph и прекращение использования модуля PowerShell.

Размах

Эта статья относится к следующим партнерам:

  • Поставщики панели управления (CPVs) — это независимые поставщики программного обеспечения, которые разрабатывают приложения для использования партнерами CSP для интеграции с API Центра партнеров. CPV не является партнером CSP с прямым доступом к панели мониторинга партнера или API. Это компании, которые разрабатывают приложения (обычно веб-приложения), которые позволяют поставщику служб csps продавать свои продукты через единую платформу.
  • Косвенные поставщики CSP и прямые партнеры CSP, использующие идентификатор приложения + проверку подлинности пользователя и напрямую интегрируются с API Центра партнеров.

Заметка

Чтобы квалифицироваться как CPV, сначала необходимо подключиться к Центру партнеров в качестве CPV. Если вы являетесь существующим партнером CSP и одновременно CPV, это необходимое условие также применяется к вам.

Разработка безопасных приложений

В процессе размещения заказов на продукты Майкрософт от имени поставщиков облачных решений приложения Marketplace от поставщиков CPV взаимодействуют с API Майкрософт для размещения заказов и предоставления ресурсов для клиентов.

Некоторые из этих API включают:

  • API Центра партнеров, реализующие коммерческие операции, такие как размещение заказов и управление жизненным циклом подписки.
  • API Microsoft Graph, реализующие управление удостоверениями для арендаторов CSP и арендаторов клиентов CSP.
  • API Azure Resource Manager (ARM), реализующие функции развертывания Azure.

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

Приложения Marketplace предназначены для того, чтобы партнеры CSP перечислили свои решения для клиентов. Для этого приложения Marketplace должны принимать на себя привилегии партнёра CSP, чтобы вызывать API Microsoft.

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

Принципы безопасности для имитации учетных данных

  • Приложения Marketplace не должны хранить учетные данные от партнеров CSP.

  • Пароли пользователей партнера CSP не должны быть общими.

  • Ключи веб-приложения клиента партнера CSP не должны предоставляться поставщикам панели управления.

  • Приложение Marketplace должно предъявлять удостоверение приложения вместе с информацией о партнере, а не только учетные данные партнера, при совершении действий от имени партнера CSP.

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

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

  • Учетные данные приложения и учетные данные партнера должны быть предоставлены вместе для получения доступа.

    Важный

    Важно, чтобы не было единой точки компромисса.

  • Доступ должен быть ограничен определенной аудиторией или API.

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

  • Разрешения доступа для приложения Marketplace должны быть привязаны к времени. Партнеры CSP должны иметь возможность продлить или отозвать доступ к приложению Marketplace.

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

  • Все учетные записи пользователей должны использовать двухфакторную проверку подлинности (2FA).

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

Заметка

Поставщики CSP и прямые партнеры CSP, которые используют проверку подлинности по идентификатору приложения и пользователю и напрямую интегрируются с API Центра партнеров, обязаны следовать приведённым выше принципам, чтобы обеспечить безопасность своих приложений в Marketplace.

Идентификация приложений и основные понятия

Мультитенантные приложения

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

Дополнительные сведения о создании мультитенантного приложения см. в статье Вход любого пользователя Microsoft Entra с помощью шаблона мультитенантного приложения.

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

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

Заметка

Косвенные поставщики CSP и прямые партнеры CSP, использующие идентификатор приложения и проверку подлинности пользователя и напрямую интегрируемые с API Центра партнеров, должны дать согласие приложению Marketplace с помощью той же платформы согласия.

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

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

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

Поток токенов открытой авторизации (OAuth) для многотенантных приложений

В потоке многотенантной авторизации приложения (OAuth) приложение представлено как мультитенантное приложение в клиенте партнера CPV или CSP.

Чтобы получить доступ к API Microsoft (API Центра партнеров, API Graph и т. д.), партнеры CSP должны войти в приложение и предоставить приложению разрешение на вызов API от их имени.

Заметка

Непрямые поставщики CSP и прямые партнеры CSP, использующие идентификатор приложения и проверку подлинности пользователя, и напрямую интегрируются с API Центра партнеров, должны дать согласие приложению Marketplace использовать ту же платформу согласия.

Приложение получает доступ к ресурсам партнера, таким как API Graph и Центра партнеров, с помощью предоставления согласия и предоставления OAuth.

Создание мультитенантного приложения

Мультитенантное приложение должно соответствовать следующим требованиям:

  • Это должно быть веб-приложение с идентификатором приложения и секретным ключом.
  • Он должен отключать неявный режим проверки подлинности.

Кроме того, рекомендуется придерживаться следующих рекомендаций:

  • Используйте сертификат для секретного ключа.
  • Включите условный доступ для применения ограничений диапазона IP-адресов. Для этого может потребоваться включить дополнительные функциональные возможности в клиенте Microsoft Entra.
  • Применение политик времени существования маркера доступа для приложения.

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

Приложение можно настроить для вызова нескольких API, включая API Azure Resource Manager. Ниже приведен минимальный набор разрешений, необходимых для API Центра партнеров:

  • Делегированные разрешения Microsoft Entra ID: Доступ к каталогу от имени вошедшего пользователя
  • Делегированные разрешения API Центра партнеров: Access

Приложение с многопользовательской архитектурой должно получить согласие от партнеров и использовать его для совершения дальнейших вызовов к API Центра партнёров. Согласие приобретается с помощью потока кода проверки подлинности OAuth.

Чтобы получить согласие, партнеры CPV или CSP должны создать веб-сайт для регистрации, который может принять предоставление кода авторизации от Microsoft Entra ID.

Дополнительные сведения см. в разделе платформа идентификации Microsoft и поток кода авторизации OAuth 2.0.

Ниже приведены шаги для мультитенантного приложения для получения согласия партнера CSP вместе с переиспользуемым маркером для вызова API Центра партнеров.

Чтобы получить согласие партнера, выполните следующие действия.

  1. Создайте веб-приложение для подключения партнера, которое может разместить ссылку для согласия, чтобы партнер мог принять согласие для использования мультитенантного приложения.
  2. Партнер CSP щелкает ссылку согласия. Например, https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_ty
  3. Страница входа Microsoft Entra объясняет разрешения, которые будут предоставлены приложению от имени пользователя. Партнер CSP может решить использовать учетные данные агента администрирования или агента продаж для входа и утверждения согласия. Приложение предоставляет разрешения на основе роли пользователя, используемой для входа.
  4. После предоставления согласия идентификатор Microsoft Entra создает субъект-службу мультитенантного приложения CPV в клиенте партнера CSP.
    • Приложению предоставлены права OAuth для действий от имени пользователя. Эти гранты позволяют мультитенантным приложениям вызывать API Центра партнеров от имени партнера.
    • На этом этапе страница входа Microsoft Entra перенаправляется на веб-приложение для подключения партнера. Веб-приложение получает код авторизации из идентификатора Microsoft Entra. Веб-приложение для подключения партнера должно использовать код авторизации вместе с идентификатором приложения и секретным ключом для обращения к API токенов Microsoft Entra ID и получения токена обновления.
  5. Безопасно храните маркер обновления. Маркер обновления является частью учетных данных партнера, используемых для получения доступа к API Центра партнеров от имени партнера. После получения токена обновления зашифруйте его и сохраните в хранилище секретных ключей, например хранилище ключей Azure.

Поток вызова запроса токена

Приложения партнера CPV или партнера CSP должны получить токен доступа перед тем, как вызывать API Центра партнеров. Эти API представлены по URL-адресу ресурса https://api.partnercenter.microsoft.com.

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

Для партнеров CSP, где есть только один арендатор, предоставляющий согласие, учетная запись партнера ссылается на арендатора самого CSP-партнера.

Маркер обновления — это маркер с несколькими аудиториями. Это означает, что обновляемый токен можно использовать для получения токена для множества аудитории на основе предоставленного согласия. Например, если предоставлено согласие партнера на использование API Центра партнеров и API Microsoft Graph, токен обновления можно использовать для запроса токена доступа для обоих API. Токен доступа имеет разрешение "от имени" и позволяет приложению маркетплейса олицетворять партнера, который дал согласие, при вызове этих API.

Маркер доступа можно получить для одной аудитории одновременно. Если приложению требуется доступ к нескольким API, он должен запрашивать несколько маркеров доступа для целевой аудитории. Чтобы запросить токен доступа, приложению необходимо вызвать API токенов идентификатора Microsoft Entra . Кроме того, можно также использовать пакет SDK Microsoft Entra AuthenticationContext.AcquireTokenAsync и передать следующие сведения:

  • URL-адрес ресурса, который является URL-адресом конечной точки для вызываемого приложения. Например, URL-адрес ресурса для API Центра партнеров Майкрософт https://api.partnercenter.microsoft.com.
  • Учетные данные приложения, состоящие из идентификатора приложения и секретного ключа веб-приложения.
  • Токен обновления

Полученный маркер доступа позволяет приложению вызывать API, упомянутые в ресурсе. Приложение не может запросить токен доступа для API, которым не были предоставлены разрешения в контексте запроса на согласие. Значение атрибута UserPrincipalName (UPN) — это имя пользователя Microsoft Entra для учетных записей пользователей.

Дополнительные рекомендации

Условный доступ

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

Дополнительные сведения см. в разделе Что такое условный доступ в идентификаторе Microsoft Entra ID?

Ограничения на основе диапазона IP

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

Многофакторная проверка подлинности

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

Дополнительные сведения см. в статье о том, как это работает: Azure Multi.

Связанное содержимое