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

Безопасный доступ к серверам MCP в службе управления API

ОБЛАСТЬ ПРИМЕНЕНИЯ: Разработчик | Базовый | Базовая версия 2 | Стандартный | Стандартная версия 2 | Премиум | Премиум версия 2

Благодаря поддержке сервера MCP в службе управления API можно предоставлять и управлять доступом к серверам MCP и их средствам. В этой статье описывается, как защитить доступ к серверам MCP, управляемым в службе управления API, включая оба сервера MCP, предоставляемые из управляемых ИНТЕРФЕЙСов REST API и существующих серверов MCP, размещенных за пределами управления API.

Вы можете защитить любой или оба входящих доступа к серверу MCP (от клиента MCP к управлению API) и исходящий доступ (от управления API до сервера MCP).

Безопасный входящий доступ

Проверка подлинности на основе ключей

Если сервер MCP защищен ключом подписки управления API, переданным в Ocp-Apim-Subscription-Key заголовке, клиенты MCP могут представить ключ в входящих запросах, а сервер MCP может проверить ключ. Например, в Visual Studio Code можно добавить headers раздел в конфигурацию сервера MCP, чтобы требовать ключ подписки в заголовках запроса:

{
  "name": "My MCP Server",
  "type": "remote",
  "url": "https://my-api-management-instance.azure-api.net/my-mcp-server",    
  "transport": "streamable-http",
  "headers": {
    "Ocp-Apim-Subscription-Key": "<subscription-key>"
  }
}

Замечание

Безопасное управление ключами подписки с помощью параметров рабочей области Visual Studio Code или безопасных входных данных.

Проверка подлинности на основе токенов (OAuth 2.1 с идентификатором Microsoft Entra)

Клиенты MCP могут представлять маркеры OAuth или JWTs, выданные идентификатором Microsoft Entra, с помощью заголовка и проверки с помощью Authorization управления API.

Например, используйте политику токена validate-azure-ad-token для проверки маркеров идентификатора Microsoft Entra:

<validate-azure-ad-token tenant-id="your-entra-tenant-id" header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">     
    <client-application-ids>
        <application-id>your-client-application-id</application-id>
    </client-application-ids> 
</validate-azure-ad-token>

Переадресация маркеров в серверную часть

Заголовки запросов автоматически перенаправляются (с определенными исключениями) в вызовы средства MCP, упрощая интеграцию с нижестоящими API, которые используют заголовки для маршрутизации, контекста или проверки подлинности.

Если для проверки входящих запросов требуется явное перенаправление заголовка Authorization , можно использовать один из следующих подходов:

  • Явным образом определяется Authorization как обязательный заголовок в параметрах API и переадресует заголовок в политике Outbound .

    Пример фрагмента политики:

    <!-- Forward Authorization header to backend --> 
<set-header name="Authorization" exists-action="override"> 
    <value>@(context.Request.Headers.GetValueOrDefault("Authorization"))</value> 
</set-header>

  • Используйте диспетчер учетных данных и политики управления API (get-authorization-context, set-header), чтобы безопасно перенаправить маркер. Дополнительные сведения см. в статье "Безопасный исходящий доступ ".

Дополнительные варианты авторизации и примеры для входящего трафика см. в следующем разделе:

Безопасный исходящий доступ

Используйте диспетчер учетных данных управления API для безопасного внедрения маркеров OAuth 2.0 для запросов серверных API, сделанных средствами сервера MCP.

Действия по настройке исходящего доступа на основе OAuth 2

Шаг 1. Зарегистрируйте приложение в поставщике удостоверений.

Шаг 2. Создайте поставщик учетных данных в службе управления API, связанной с поставщиком удостоверений.

Шаг 3. Настройте подключения в диспетчере учетных данных.

Шаг 4. Примените политики управления API для динамического получения учетных данных и присоединения учетных данных.

Например, следующая политика получает маркер доступа из диспетчера учетных данных и задает его в Authorization заголовке исходящего запроса:

<!-- Add to inbound policy. -->
<get-authorization-context
    provider-id="your-credential-provider-id" 
    authorization-id="auth-01" 
    context-variable-name="auth-context" 
    identity-type="managed" 
    ignore-error="false" />
<!-- Attach the token to the backend call -->
<set-header name="Authorization" exists-action="override">
    <value>@("Bearer " + ((Authorization)context.Variables.GetValueOrDefault("auth-context"))?.AccessToken)</value>
</set-header>

Пошаговое руководство по вызову примера серверной части с использованием учетных данных, созданных в диспетчере учетных данных, см. в разделе "Настройка диспетчера учетных данных " GitHub".

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

  • Last updated on