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

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

  • Статья

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

Внимание

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

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

Дополнительные сведения см. в статье "Важно: выход на пенсию в Azure AD Graph и отключение модуля PowerShell".

Область

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Внимание

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

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

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

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

  • Для обработки компрометации учетных данных приложения 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: доступ к каталогу как вошедшего пользователя
  • Делегированные разрешения API Центра партнеров: Access

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

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

Дополнительные сведения см. в статье "Авторизация доступа к веб-приложениям Azure Active и Directory" с помощью потока предоставления кода 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.

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

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

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

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

Маркер обновления — это маркер с несколькими аудиторией. Это означает, что маркер обновления можно использовать для получения маркера для нескольких аудиторий на основе предоставленного согласия. Например, если для API Центра партнеров и API Microsoft Graph предоставлено согласие партнера, маркер обновления можно использовать для запроса маркера доступа для обоих API. Маркер доступа имеет предоставление "от имени" и позволяет приложению Marketplace олицетворить партнера, который согласился при вызове этих 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 проверить удостоверение вызывающего абонента через безопасные вторичные каналы, такие как мобильные или электронные письма, перед выдачой маркеров.

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

Связанный контент