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

Безопасный гибридный доступ с помощью интеграции Microsoft Entra

  • Статья

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

Дополнительные сведения: безопасность нулевого доверия

Идентификатор Microsoft Entra id изначально поддерживает современные протоколы:

  • Язык разметки заявлений системы безопасности (SAML)
  • Федерация веб-служб (WS-Fed)
  • OpenID Connect (OIDC)

Прокси приложения Microsoft Entra или прокси приложения Microsoft Entra поддерживает проверку подлинности kerberos и на основе заголовков. Другие протоколы, такие как Secure Shell (SSH), (Microsoft Windows NT LAN Manager) NTLM, протокол LDAP и файлы cookie, не поддерживаются. Но независимые поставщики программного обеспечения (НЕЗАВИСИМЫе поставщики программного обеспечения) могут создавать решения для подключения этих приложений с идентификатором Microsoft Entra.

Поставщики программного обеспечения могут помочь клиентам обнаруживать и переносить приложения как услуга (SaaS) в идентификатор Microsoft Entra. Они могут подключать приложения, использующие устаревшие методы проверки подлинности с идентификатором Microsoft Entra. Клиенты могут объединиться с идентификатором Microsoft Entra, чтобы упростить управление приложениями и реализовать принципы нулевого доверия.

Обзор решения

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

  • Обнаружение приложений . Часто клиенты не знают о каждом используемом приложении
    • Обнаружение приложений находит приложения, упрощая интеграцию приложений с идентификатором Microsoft Entra
  • Миграция приложений— создание рабочего процесса для интеграции приложений с идентификатором Microsoft Entra без использования Центра администрирования Microsoft Entra
    • Интеграция приложений, которые клиенты используют сегодня
  • Поддержка устаревшей проверки подлинности — Подключение приложения с устаревшими методами проверки подлинности и единым входом (единый вход)
  • Условный доступ . Разрешить клиентам применять политики Microsoft Entra к приложениям в решении без использования Центра администрирования Microsoft Entra

Дополнительные сведения: Что такое условный доступ?

Ознакомьтесь со следующими разделами, чтобы ознакомиться с техническими рекомендациями и рекомендациями.

Публикация приложений в Azure Marketplace

Azure Marketplace является для ИТ-администраторов доверенным источником приложений. Приложения совместимы с идентификатором Microsoft Entra и поддерживают единый вход, автоматизацию подготовки пользователей и интеграцию с внешними клиентами с автоматической регистрацией приложений.

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

Мы рекомендуем стать проверенным издателем, поэтому клиенты знают, что вы доверенный издатель. См. проверку издателя.

Включение единого входа для ИТ-администраторов

Существует несколько способов включения единого входа для ИТ-администраторов в решение. См. раздел " Планирование развертывания единого входа" и "Параметры единого входа".

В Microsoft Graph применяется OIDC/OAuth. Клиенты используют OIDC для входа в решение. Используйте проблемы с идентификатором идентификатора Microsoft Entra в формате JSON (JWT) для взаимодействия с Microsoft Graph. См. Подключение OpenID на платформа удостоверений Майкрософт.

Если решение использует SAML для единого входа ИТ-администратора, токен SAML не позволит вашему решению взаимодействовать с Microsoft Graph. Вы можете использовать SAML для единого входа ИТ-администратора, но решение должно поддерживать интеграцию OIDC с идентификатором Microsoft Entra ID, чтобы он смог получить JWT из идентификатора Microsoft Entra для взаимодействия с Microsoft Graph. См. сведения о том, как платформа удостоверений Майкрософт использует протокол SAML.

Вы можете использовать один из следующих подходов SAML:

Используйте тип предоставления учетных данных клиента, который требует, чтобы решение позволило клиентам вводить идентификатор клиента и секрет. Для решения также требуется хранить эти сведения. Получите JWT из идентификатора Microsoft Entra, а затем используйте его для взаимодействия с Microsoft Graph. См. раздел " Получение маркера". Мы рекомендуем выполнить повторную документацию по клиенту о том, как создать регистрацию приложений в клиенте Microsoft Entra. Включите конечные точки, URI и разрешения.

Примечание.

Прежде чем приложения используются для единого входа ИТ-администратора или пользователя, ИТ-администратор клиента должен согласиться с приложением в своем клиенте. См. предоставление согласия администратора на уровне клиента приложению.

Потоки проверки подлинности

Потоки проверки подлинности решения поддерживают следующие сценарии:

  • ИТ-администратор клиента входит в систему с помощью единого входа для администрирования решения.
  • ИТ-администратор клиента использует решение для интеграции приложений с идентификатором Microsoft Entra с Microsoft Graph
  • Пользователи войдите в устаревшие приложения, защищенные вашим решением и идентификатором Microsoft Entra

ИТ-администратор клиента выполняет единый вход в решение.

Решение может использовать SAML или OIDC для единого входа, когда ИТ-администратор клиента входит в систему. Мы рекомендуем ИТ-администратору войти в решение с помощью учетных данных Microsoft Entra, что позволяет использовать текущие элементы управления безопасностью. Интеграция с идентификатором Microsoft Entra для единого входа с помощью SAML или OIDC.

На следующей схеме показан поток проверки подлинности пользователя:

Схема администратора, перенаправленного на идентификатор Microsoft Entra для входа, а затем перенаправлена в решение.

  1. ИТ-администратор входит в решение с помощью учетных данных Microsoft Entra
  2. Решение перенаправляет ИТ-администратора в идентификатор Microsoft Entra с помощью SAML или запроса на вход в OIDC
  3. Microsoft Entra проверяет подлинность ИТ-администратора и перенаправляет их в решение с помощью токена SAML или JWT, который будет авторизован в решении.

ИТ-администраторы интегрируют приложения с идентификатором Microsoft Entra

ИТ-администраторы интегрируют приложения с идентификатором Microsoft Entra с помощью решения, которое использует Microsoft Graph для создания регистраций приложений и политик условного доступа Microsoft Entra.

На следующей схеме показан поток проверки подлинности пользователя:

Схема взаимодействия между ИТ-администратором, идентификатором Microsoft Entra, решением и Microsoft Graph.

  1. ИТ-администратор входит в решение с помощью учетных данных Microsoft Entra
  2. Решение перенаправляет ИТ-администратора в идентификатор Microsoft Entra с помощью SAML или запроса на вход в OIDC
  3. Microsoft Entra проверяет подлинность ИТ-администратора и перенаправляет их в решение с помощью токена SAML или JWT для авторизации
  4. Когда ИТ-администратор интегрирует приложение с идентификатором Microsoft Entra, решение вызывает Microsoft Graph с помощью JWT для регистрации приложений или применения политик условного доступа Microsoft Entra

Вход пользователей в приложения

При входе пользователей в приложения они используют OIDC или SAML. Если приложениям необходимо взаимодействовать с Защищенным API Microsoft Graph или Microsoft Entra, рекомендуется настроить их для использования OICD. Эта конфигурация гарантирует применение JWT для взаимодействия с Microsoft Graph. Если приложений не требуется взаимодействовать с Microsoft Graph или защищенными API Microsoft Entra, используйте SAML.

На следующей схеме показан поток проверки подлинности пользователей:

Схема взаимодействия между пользователем, идентификатором Microsoft Entra, решением и приложением.

  1. Пользователь входит в приложение
  2. Решение перенаправляет пользователя на идентификатор Microsoft Entra с помощью SAML или запроса на вход в OIDC
  3. Microsoft Entra проверяет подлинность пользователя и перенаправляет их в решение с помощью токена SAML или JWT для авторизации
  4. Решение разрешает запрос с помощью протокола приложения

API Microsoft Graph

Рекомендуется использовать следующие API. Используйте идентификатор Microsoft Entra для настройки делегированных разрешений или разрешений приложения. Для этого решения используйте делегированные разрешения.

  • API шаблонов приложений. В Azure Marketplace используйте этот API для поиска соответствующего шаблона приложения.
    • Необходимые разрешения: Application.Read.All
  • API регистрации приложений— создание регистрации приложений OIDC или SAML для пользователей, защищенных с помощью вашего решения
    • Необходимые разрешения: Application.Read.All, Application.ReadWrite.All
  • API субъекта-службы. После регистрации приложения обновите объект субъекта-службы, чтобы задать свойства единого входа.
    • Необходимые разрешения: Application.ReadWrite.All, Directory.AccessAsUser.All, AppRoleAssignment.ReadWrite.All (для назначения)
  • API условного доступа . Применение политик условного доступа Microsoft Entra к пользовательским приложениям
    • Необходимые разрешения: Policy.Read.All, Policy.ReadWrite.ConditionalAccess и Application.Read.All

Дополнительные сведения об использовании API Microsoft Graph

Сценарии API Microsoft Graph

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

Использование API Microsoft Graph для регистрации приложений с помощью идентификатора Microsoft Entra

Добавление приложений в Azure Marketplace

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

Примечание.

В API шаблонов приложений отображаемое имя учитывает регистр.

Authorization: Required with a valid Bearer token
Method: Get

https://graph.microsoft.com/v1.0/applicationTemplates?$filter=displayname eq "Salesforce.com"

Если вы нашли совпадение из вызова API, зафиксировать идентификатор. Выполните следующий вызов API и укажите отображаемое имя приложения в тексте JSON:

Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json

https://graph.microsoft.com/v1.0/applicationTemplates/cd3ed3de-93ee-400b-8b19-b61ef44a0f29/instantiate
{
    "displayname": "Salesforce.com"
}

После вызова API создается объект субъекта-службы. Зафиксировать идентификатор приложения и идентификатор субъекта-службы для использования в следующих вызовах API.

Исправление объекта субъекта-службы с помощью протокола SAML и URL-адреса входа:

Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: servicePrincipal/json

https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
{
    "preferredSingleSignOnMode":"saml",
    "loginURL": "https://www.salesforce.com"
}

Исправление объекта приложения с помощью URI перенаправления и URI идентификатора:

Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: application/json

https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444
{
    "web": {
    "redirectUris":["https://www.salesforce.com"]},
    "identifierUris":["https://www.salesforce.com"]
}

Добавление приложений, не входящих в Azure Marketplace

Если в Azure Marketplace нет совпадений или интегрировать пользовательское приложение, зарегистрируйте пользовательское приложение в идентификаторе Microsoft Entra с идентификатором шаблона: 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Затем выполните следующий вызов API и укажите отображаемое имя приложения в тексте JSON:

Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json

https://graph.microsoft.com/v1.0/applicationTemplates/8adf8e6e-67b2-4cf2-a259-e3dc5476c621/instantiate
{
    "displayname": "Custom SAML App"
}

После вызова API создается объект субъекта-службы. Зафиксировать идентификатор приложения и идентификатор субъекта-службы для использования в следующих вызовах API.

Исправление объекта субъекта-службы с помощью протокола SAML и URL-адреса входа:

Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: servicePrincipal/json

https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
{
    "preferredSingleSignOnMode":"saml",
    "loginURL": "https://www.samlapp.com"
}

Исправление объекта приложения с помощью URI перенаправления и URI идентификаторов:

Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: application/json

https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444
{
    "web": {
    "redirectUris":["https://www.samlapp.com"]},
    "identifierUris":["https://www.samlapp.com"]
}

Использование единого входа Microsoft Entra

После регистрации приложений SaaS в идентификаторе Microsoft Entra приложения должны начать использовать идентификатор Microsoft Entra в качестве поставщика удостоверений (IdP):

Подключение приложениям в идентификатор Microsoft Entra с устаревшей проверкой подлинности

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

Создание регистрации приложения SAML

Используйте следующий пользовательский идентификатор шаблона приложения: 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Затем выполните следующий вызов API и укажите отображаемое имя в тексте JSON:

Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json

https://graph.microsoft.com/v1.0/applicationTemplates/8adf8e6e-67b2-4cf2-a259-e3dc5476c621/instantiate
{
    "displayname": "Custom SAML App"
}

После вызова API создается объект субъекта-службы. Зафиксировать идентификатор приложения и идентификатор субъекта-службы для использования в следующих вызовах API.

Исправление объекта субъекта-службы с помощью протокола SAML и URL-адреса входа:

Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: servicePrincipal/json

https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
{
    "preferredSingleSignOnMode":"saml",
    "loginURL": "https://www.samlapp.com"
}

Исправление объекта приложения с помощью URI перенаправления и URI идентификаторов:

Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: application/json

https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444
{
    "web": {
    "redirectUris":["https://www.samlapp.com"]},
    "identifierUris":["https://www.samlapp.com"]
}

Создание регистрации приложения OIDC

Используйте следующий идентификатор шаблона для пользовательского приложения: 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Выполните следующий вызов API и укажите отображаемое имя в тексте JSON:

Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json

https://graph.microsoft.com/v1.0/applicationTemplates/8adf8e6e-67b2-4cf2-a259-e3dc5476c621/instantiate
{
    "displayname": "Custom OIDC App"
}

Из вызова API зафиксировать идентификатор приложения и идентификатор субъекта-службы для использования в следующих вызовах API.

Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: application/json

https://graph.microsoft.com/v1.0/applications/{Application Object ID}
{
    "web": {
    "redirectUris":["https://www.samlapp.com"]},
    "identifierUris":["[https://www.samlapp.com"],
    "requiredResourceAccess": [
    {
        "resourceAppId": "00000003-0000-0000-c000-000000000000",
        "resourceAccess": [
        {
            "id": "7427e0e9-2fba-42fe-b0c0-848c9e6a8182",
            "type": "Scope"
        },
        {
            "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
            "type": "Scope"
        },
        {
            "id": "37f7f235-527c-4136-accd-4a02d197296e",
            "type": "Scope"
        }]
    }]
}

Примечание.

Разрешения API на resourceAccess узле предоставляют приложению разрешения openid, User.Read и offline_access, которые обеспечивают вход. См. общие сведения о разрешениях Microsoft Graph.

Применение политик условного доступа

Клиенты и партнеры могут использовать API Microsoft Graph для создания или применения политик условного доступа приложения. Для партнеров клиенты могут применять эти политики из решения без использования Центра администрирования Microsoft Entra. Существует два варианта применения политик условного доступа Microsoft Entra:

Использование политики условного доступа

Для списка политик условного доступа выполните следующий запрос. Получите идентификатор объекта политики для изменения.

Authorization: Required with a valid Bearer token
Method:GET

https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies

Чтобы исправить политику, добавьте идентификатор объекта приложения, который должен находиться в область includeApplicationsв тексте JSON:

Authorization: Required with a valid Bearer token
Method: PATCH

https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/{policyid}
{
    "displayName":"Existing Conditional Access Policy",
    "state":"enabled",
    "conditions": 
    {
        "applications": 
        {
            "includeApplications":[
                "00000003-0000-0ff1-ce00-000000000000", 
                "{Application Object ID}"
            ]
        },
        "users": {
            "includeUsers":[
                "All"
            ] 
        }
    },
    "grantControls": 
    {
        "operator":"OR",
        "builtInControls":[
            "mfa"
        ]
    }
}

Создание политики условного доступа

Добавьте идентификатор объекта приложения, который должен находиться в область includeApplicationsв тексте JSON:

Authorization: Required with a valid Bearer token
Method: POST

https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/
{
    "displayName":"New Conditional Access Policy",
    "state":"enabled",
    "conditions": 
    {
        "applications": {
            "includeApplications":[
                "{Application Object ID}"
            ]
        },
        "users": {
            "includeUsers":[
                "All"
            ]
        }
    },
    "grantControls": {
        "operator":"OR",
        "builtInControls":[
            "mfa"
        ]
    }
}

#Policy Template for Requiring Compliant Device

{
    "displayName":"Enforce Compliant Device",
    "state":"enabled",
    "conditions": {
        "applications": {
            "includeApplications":[
                "{Application Object ID}"
            ]
        },
        "users": {
            "includeUsers":[
                "All"
            ]
        }
    },
    "grantControls": {
        "operator":"OR",
        "builtInControls":[
            "compliantDevice",
            "domainJoinedDevice"
        ]
    }
}

#Policy Template for Block

{
    "displayName":"Block",
    "state":"enabled",
    "conditions": {
        "applications": {
            "includeApplications":[
                "{Application Object ID}"
            ]
        },
        "users": {
            "includeUsers":[
                "All"
            ] 
        }
    },
    "grantControls": {
        "operator":"OR",
        "builtInControls":[
            "block"
        ]
    }
}

Если клиент добавляет приложения из решения в идентификатор Microsoft Entra ID, вы можете автоматизировать согласие администратора с помощью Microsoft Graph. Вам нужен идентификатор объекта субъекта-службы приложения, созданный в вызовах API, и идентификатор объекта субъекта-службы Microsoft Graph из внешнего клиента.

Получите идентификатор объекта субъекта-службы Microsoft Graph, выполнив следующий вызов API:

Authorization: Required with a valid Bearer token
Method:GET

https://graph.microsoft.com/v1.0/serviceprincipals/?$filter=appid eq '00000003-0000-0000-c000-000000000000'&$select=id,appDisplayName

Чтобы автоматизировать согласие администратора, выполните следующий вызов API:

Authorization: Required with a valid Bearer token
Method: POST
Content-type: application/json

https://graph.microsoft.com/v1.0/oauth2PermissionGrants
{
    "clientId":"{Service Principal Object ID of Application}",
    "consentType":"AllPrincipals",
    "principalId":null,
    "resourceId":"{Service Principal Object ID Of Microsoft Graph}",
    "scope":"openid user.read offline_access}"
}

Получение сертификата для подписи маркера

Чтобы получить общедоступную часть сертификата подписи маркера, используйте GET из конечной точки метаданных Microsoft Entra для приложения:

Method:GET

https://login.microsoftonline.com/{Tenant_ID}/federationmetadata/2007-06/federationmetadata.xml?appid={Application_ID}

Назначить пользователей и группы

После публикации приложения в идентификатор Microsoft Entra можно назначить приложение пользователям и группам, чтобы убедиться, что оно отображается на портале Мои приложения. Это назначение находится в объекте субъекта-службы, созданном при создании приложения. Ознакомьтесь с обзором портала Мои приложения.

Получение AppRole экземпляров приложения, возможно, связано с ним. Для приложений SaaS характерно иметь разные связанные экземпляры AppRole. Как правило, для пользовательских приложений существует один экземпляр по умолчанию AppRole . Получите идентификатор экземпляра AppRole , который вы хотите назначить:

Authorization: Required with a valid Bearer token
Method:GET

https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222

В идентификаторе Microsoft Entra получите идентификатор пользователя или объекта группы, который вы хотите назначить приложению. Возьмите идентификатор роли приложения из предыдущего вызова API и отправьте его с текстом исправления на субъекте-службе:

Authorization: Required with a valid Bearer token
Method: PATCH
Content-type: servicePrincipal/json

https://graph.microsoft.com/v1.0/servicePrincipals/aaaaaaaa-bbbb-cccc-1111-222222222222
{
    "principalId":"{Principal Object ID of User -or- Group}",
    "resourceId":"{Service Principal Object ID}",
    "appRoleId":"{App Role ID}"
}

Партнерство

Чтобы защитить устаревшие приложения, используя сетевые и контроллеры доставки, корпорация Майкрософт имеет партнерские отношения со следующими поставщиками контроллера доставки приложений (ADC).

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

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