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

Требование многофакторной аутентификации (MFA) для партнерского арендатора

  • Статья

Соответствующие роли: Администратор | Агент по продажам | Агент службы поддержки | Администратор выставления счетов | Администратор безопасности

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

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

В этой статье приведены подробные примеры и рекомендации по настройке многофакторной проверки подлинности (MFA) в Центре партнеров.

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

Партнеры обязаны применять многофакторную проверку подлинности (MFA) для всех учетных записей пользователей в своем партнерском аккаунте, включая гостевых пользователей. Пользователи должны выполнить проверку MFA для следующих областей:

Центр партнеров

Некоторые страницы в Центре партнеров защищаются многофакторной аутентификацией, в том числе:

  • Все страницы на вкладке Клиенты (то есть все страницы с URL-адресом, начинающимся с https://partner.microsoft.com/commerce/*)
  • Все страницы на вкладке Поддержка>Запросы клиентов (например, все страницы, к которым обращается URL-адрес, начинающийся с https://partner.microsoft.com/dashboard/v2/support/customers/*)
  • Все страницы на вкладке "Выставление счетов"

Другие страницы в Центре партнеров, такие как обзорная страница и страница контроля состояния работоспособности служб, не требуют многофакторной аутентификации.

В следующей таблице показано, какие типы пользователей авторизованы для доступа к этим страницам с защитой MFA (и влияют на эту функцию).

Страница, защищенная с помощью MFA Агенты администрирования Агенты по продажам Агенты службы технической поддержки Администратор безопасности Администратор выставления счетов
Все страницы под вкладкой Клиенты x x x
Все страницы на вкладке "Поддержка Запросы клиентов" x x
Страница выставления счетов x x x
Рабочая область безопасности x x

Чтобы получить доступ к этим страницам, необходимо сначала выполнить проверку MFA.

Поддерживаемые параметры MFA

  • Партнеры, использующие поддерживаемую Microsoft многофакторную аутентификацию Microsoft Entra. Дополнительные сведения см. в разделе «Несколько способов включения многофакторной проверки подлинности Microsoft Entra» (MFA поддерживается Microsoft Entra).
  • Партнеры, которые реализовали интегрированную федеративную проверку подлинности MFA. Эти пользователи-партнеры могут получить доступ к Центру партнеров и управлять клиентами с помощью GDAP. Узнайте о встроенных поставщиках MFA и доступных предложениях MFA в AD FS: настройка методов для AD FS.

Внимание

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

Центр партнеров и интерфейсы API

Для следующих API Центра партнеров требуются доступ приложений и пользователей (App+User access) и поддержка многофакторной аутентификации (MFA) Microsoft Entra ID.

  • Ознакомьтесь с (ценой/каталогом/продвижением)
  • Совершайте транзакции и управляйте
  • Выставление счетов и выверка
  • Управление клиентами с помощью делегированного доступа/AOBO
  • Назначение пользователей и лицензий (только с DAP)
  • Назначение пользователей и лицензий (с GDAP)
  • Детализированные административные связи: запрос и назначение доступа

Для партнеров доступны следующие варианты:

Примеры проверки

Чтобы иллюстрировать работу проверки в Центре партнеров, рассмотрим следующие примеры.

Пример 1. Партнер реализовал многофакторную проверку подлинности Microsoft Entra

  1. Alejandra работает для CSP с именем Contoso. Компания Contoso реализовала MFA для всех пользователей в клиенте партнера Contoso с помощью многофакторной проверки подлинности Microsoft Entra.

  2. Alejandra запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Алехандру в Microsoft Entra ID для входа.

  3. Из-за существующего многофакторного метода аутентификации Microsoft Entra, установленного компанией Contoso, Алехандре необходимо пройти проверку MFA. После успешного входа в систему и успешной проверки MFA Алехандра перенаправляется обратно на обзорную страницу Центра партнеров.

  4. Alejandra пытается получить доступ к одной из страниц, защищенных MFA, в Центре партнеров. Так как Alejandra завершил проверку MFA во время входа ранее, Alejandra может получить доступ к защищенной MFA странице без необходимости повторно пройти проверку MFA.

Пример 2. Партнер внедрил MFA, не связанный с Microsoft, с помощью федерации удостоверений

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

  2. Prashob запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Prashob на идентификатор Microsoft Entra для входа.

  3. Поскольку Wingtip настроил федерацию удостоверений, Microsoft Entra ID перенаправляет Prashob к федеративному поставщику удостоверений, чтобы завершить вход и проверку многофакторной аутентификации (MFA). После успешного входа и проверки MFA Прашоб перенаправляется обратно в Microsoft Entra ID, а затем на страницу обзора Центра партнеров.

  4. Prashob пытается получить доступ к одной из страниц, защищенных MFA, в Центре партнеров. Так как Prashob уже завершил проверку MFA во время входа ранее, он может получить доступ к защищенной странице MFA, не требуя повторной проверки MFA.

  5. Затем Prashob переходит на страницу управления учетными записями, чтобы добавить пользователей в Microsoft Entra ID компании Contoso. Так как Prashob использовал поставщика проверки подлинности, совместимого с Entra, со строгой проверкой подлинности, он может получить доступ к клиентскому арендатору без каких-либо проблем.

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

Пример 3. Партнер не реализовал MFA

  1. Партнер CSP с именем Fabrikam еще не реализовал MFA. Корпорация Майкрософт рекомендует реализовать решение MFA, поддерживаемое идентификатором Microsoft Entra.

  2. Джон работает на Fabrikam. Fabrikam не реализовал MFA для пользователей в клиенте партнера Fabrikam.

  3. Джон запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Джона на Microsoft Entra ID для входа.

  4. После успешного входа Джон перенаправляется обратно на страницу обзора Центра партнеров, так как он не завершил проверку MFA.

  5. Он пытается перейти на одну из страниц в Центре партнеров, защищенных с помощью MFA. Поскольку Джон не завершил проверку многофакторной аутентификации (MFA), Центр партнеров перенаправляет его на Microsoft Entra ID для завершения проверки MFA. Поскольку это первый раз, когда Джон должен пройти MFA, Джон также должен зарегистрироваться для MFA. После успешной регистрации MFA и проверки MFA Джон может получить доступ к странице, защищенной MFA.

  6. В другой день, прежде чем Fabrikam реализует MFA для любого пользователя, Джон запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Джона в идентификатор Microsoft Entra для входа без запроса MFA.

  7. Он пытается перейти на одну из страниц в Центре партнеров, защищенных с помощью MFA. Так как Джон не завершил проверку MFA, Центр партнеров перенаправляет Джона на службу Microsoft Entra ID для завершения проверки MFA. Так как Джон зарегистрировал MFA, на этот раз ему требуется завершить проверку MFA.

Пример 4. Партнер внедрил не-Microsoft MFA, который несовместим с Microsoft Entra.

  1. Trent работает для CSP с именем Wingtip. Wingtip реализовал MFA для всех своих пользователей в клиенте партнера Wingtip, используя не Microsoft MFA в облачной среде с условным доступом.

  2. Трент запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Trent на идентификатор Microsoft Entra для входа.

  3. Так как Wingtip использовал интеграцию mFA, не совместимую с идентификатором Microsoft Entra и не имеет строгой проверки подлинности, Trent будет заблокирован доступ ко всем защищенным страницам и API MFA в Центре партнеров.

Так как Трент обращается к страницам, защищённым многофакторной аутентификацией (MFA), ему необходимо пройти строгую проверку подлинности для получения доступа к этим страницам.

Партнёры должны использовать поставщика аутентификации, совместимого с идентификатором Microsoft Entra, который поддерживает метод аутентификации ("утверждение amr" в справочнике по утверждениям маркера доступа — Платформа идентификации Microsoft), отражающий фактический тип учетных данных, предоставленный во время проверки подлинности.

Мы настоятельно рекомендуем партнерам CSP реализовать MFA, совместимую с идентификатором Microsoft Entra ID немедленно, чтобы повысить базовые показатели безопасности вашего клиента.

API Центра партнеров

API Центра партнеров поддерживает проверку подлинности только для приложений, а также проверку подлинности пользователей (App+User).

При использовании процесса аутентификации App+User Центр партнеров требует многофакторной аутентификации. В частности, когда партнерское приложение отправляет запрос API в Центр партнеров, он должен включать маркер доступа в заголовок авторизации запроса.

Примечание.

Фреймворк Secure Application Model — это масштабируемый фреймворк для аутентификации партнеров CSP и CPV через архитектуру Microsoft Azure MFA при вызове API Центра партнеров. Эту платформу необходимо реализовать при использовании MFA в службе автоматизации служб.

Когда Центр партнеров получает запрос API с маркером доступа, полученным с помощью проверки подлинности App+User, API Центра партнеров проверяет наличие значения MFA в утверждении "Справочник по методу проверки подлинности" (AMR). С помощью декодера JWT можно проверить, содержит ли маркер доступа ожидаемое значение ссылки на метод проверки подлинности (AMR).

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

  • Если это значение присутствует, Центр партнеров убедится, что проверка MFA выполнена, и обработает запрос к API.

  • Если значение отсутствует, API Центра партнеров отклоняет запрос со следующим ответом:

    HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

При вызове API Partner Center токены доступа только для приложений поддерживаются только для операций, которые не требуют назначения ролей GDAP в клиентском арендаторе.

Чтобы узнать больше о лучших практиках, ознакомьтесь с разделом «Проверка подлинности и авторизация API: Обзор».

Делегированное партнёрам администрирование

Арендаторы партнеров должны использовать гранулярные делегированные права администратора (GDAP) для управления ресурсами клиентов через порталы Microsoft Online Services (portal.azure.com или admin.microsoft.com), интерфейс командной строки (CLI) и API (с использованием проверки подлинности App+User). Дополнительные сведения см. в разделе поддерживаемые опции MFA.

Использование порталов служб

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

При доступе к порталам Microsoft Online Services с делегированными правами администратора партнера (Admin-On-Behalf-Of) для управления ресурсами клиентов, многие из этих порталов требуют, чтобы учетная запись партнера аутентифицировалась интерактивно с использованием клиента Microsoft Entra в качестве контекста аутентификации. Для входа в арендатора клиента требуется учетная запись партнера.

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

  • Если учетная запись партнера является управляемым удостоверением, Microsoft Entra ID напрямую предложит пользователю пройти проверку с помощью многофакторной аутентификации (MFA). Если учетная запись партнера не зарегистрирована для MFA с идентификатором Microsoft Entra ID раньше, пользователю будет предложено сначала завершить регистрацию MFA.

  • Если учетная запись партнера является федеративной, опыт работы зависит от того, как администратор партнера настроил федерацию в Microsoft Entra ID. При настройке федерации в Microsoft Entra ID администратор партнера может указать, поддерживает ли федеративный поставщик удостоверений многофакторную аутентификацию (MFA) или нет.

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

Общий опыт похож на сценарий, когда конечный пользователь, арендатор внедрил MFA для своих администраторов. Например, арендатор клиента включил параметры безопасности Microsoft Entra, которые требуют, чтобы все учетные записи с правами администратора входили в арендатор клиента с использованием многофакторной аутентификации (MFA), включая агентов-администраторов и агентов службы поддержки.

В целях тестирования партнеры могут включить значения безопасности по умолчанию Microsoft Entra в клиенте арендатора, а затем попытаться использовать права детализированного делегированного администрирования партнера (GDAP) для доступа к арендатору клиента.

Примечание.

Не все порталы Microsoft Online Service требуют, чтобы учетные записи партнеров входить в клиент клиента при доступе к ресурсам клиентов с помощью GDAP. Вместо этого в некоторых случаях для входа в раздел партнера требуются только учетные записи партнеров. Примером является центр администрирования Exchange. Со временем мы ожидаем, что эти порталы потребуют, чтобы учетные записи партнеров входили в клиентскую среду при использовании GDAP.

Процесс регистрации MFA и полученные впечатления

При проверке MFA, если учетная запись партнера не зарегистрирована для MFA раньше, идентификатор Microsoft Entra предложит пользователю сначала завершить регистрацию MFA.

Ознакомьтесь с дополнительной информацией о методе Microsoft Authenticator.

Screenshot of the first step in MFA registration.Снимок экрана: первый шаг регистрации MFA.

После нажатия кнопки "Далее" пользователю предлагается выбрать из списка методов проверки.

Screenshot of the second step in MFA registration.Скриншот второго шага регистрации MFA.

После успешной регистрации пользователь должен завершить проверку MFA с помощью выбранного метода проверки.

Распространенные проблемы

Чтобы понять, является ли запрос допустимым, просмотрите список распространенных проблем, сообщаемых другими партнерами.

Проблема 1. Партнеру требуется больше времени для реализации MFA для своих партнеров

Партнер еще не начал или не завершил реализацию MFA для своих агентов, которым требуется доступ к порталам Microsoft Online Services для управления ресурсами клиентов с помощью делегированных прав администратора партнера. Партнеру требуется больше времени, чтобы завершить реализацию MFA. Является ли это веской причиной для технического исключения?

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

Примечание.

Несмотря на то, что партнер не реализовал MFA для своих агентов партнеров, агенты партнеров по-прежнему могут получать доступ к порталам Microsoft Online Services с помощью привилегий делегированного администрирования партнера, если они могут завершить регистрацию MFA и проверку MFA при появлении запроса во время входа в клиент клиента. Завершение регистрации в MFA не активирует MFA для пользователя автоматически.

Проблема 2. Партнер не реализовал MFA, так как им не нужен доступ к управлению клиентами

У партнера есть некоторые пользователи в своих клиентах партнеров, которые не требуют доступа к порталам Microsoft Online Services для управления ресурсами клиентов с помощью привилегий делегированного администрирования партнера. Этот партнер находится в процессе реализации MFA для этих пользователей, и для его завершения требуется больше времени. Является ли это веской причиной для технического исключения?

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

Проблема 3. Партнер не реализовал MFA для учетных записей службы пользователей

У партнёра в их арендаторах есть некоторые учетные записи пользователей, которые используются устройствами как учетные записи службы. Эти учетные записи с низким уровнем привилегий не требуют доступа к Центру партнеров или порталам Microsoft Online Services для управления ресурсами клиентов с помощью привилегий делегированного администрирования партнера. Является ли это допустимой причиной технического исключения?

Ответ: Нет. Так как эти учетные записи пользователей не используют права делегированного администрирования партнера для управления ресурсами клиентов, им не требуется входить в систему клиента. Они не будут затронуты идентификацией Microsoft Entra, требующей проверки MFA во время входа в клиентский тенант. Если API или портал требует проверки подлинности приложения и пользователя, каждый пользователь должен использовать MFA для проверки подлинности.

Проблема 4. Партнер не может реализовать MFA с помощью приложения Microsoft Authenticator

Партнер имеет политику "чистого стола", которая не позволяет сотрудникам принести свои личные мобильные устройства в рабочую область. Без доступа к личным мобильным устройствам сотрудники не могут установить приложение Microsoft Authenticator, которое является единственной проверкой MFA, поддерживаемой по умолчанию безопасности Microsoft Entra. Является ли это веской причиной для технического исключения?

Ответ: Нет. Партнер должен рассмотреть следующую альтернативу, чтобы их сотрудники по-прежнему могли завершить проверку MFA при доступе к Центру партнеров:

  • Партнер также может зарегистрироваться в Microsoft Entra ID P1 или P2 или использовать решения, отличные от Майкрософт MFA, совместимые с идентификатором Microsoft Entra, которые могут предоставлять дополнительные методы проверки. Дополнительные сведения см. в статье Поддерживаемые методы проверки подлинности.

Проблема 5. Партнер не может реализовать MFA из-за использования устаревших протоколов проверки подлинности

Некоторые агенты партнера все еще используют устаревшие протоколы аутентификации, не совместимые с MFA. Например, пользователи по-прежнему используют приложение Outlook 2010, основанное на устаревших протоколах аутентификации. Включение MFA для этих агентов партнера нарушит работу устаревших протоколов аутентификации. Является ли это веской причиной для технического исключения?

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

Чтобы понять последний план поддержки устаревшей проверки подлинности для Outlook, ознакомьтесь со статьей в блоге об базовой проверке подлинности и Exchange Online и подписывайтесь на блог команды Exchange, чтобы узнавать последние новости.

Проблема 6: Партнер внедрил многофакторную аутентификацию от другого поставщика, которая не распознается Microsoft Entra ID.

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

Ответ. Нет, партнеры должны использовать поставщика проверки подлинности, совместимого с Entra ID от Microsoft, который поддерживает утверждение метода аутентификации ("AMR"), справочник по утверждениям маркера доступа — платформа удостоверений Microsoft, что отражает фактический тип учетных данных, используемых во время проверки подлинности.

Мы настоятельно рекомендуем реализовать MFA, совместимую с идентификатором Microsoft Entra ID, немедленно повысить базовые показатели безопасности клиента.

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

  • Статус требований к безопасности партнера