Четыре шлюза вместо одного токена: AWS показала авторизацию MCP-инструментов в Amazon Quick

Аутентификация больше не равна авторизации

Отправная точка разбора: каждый вызов инструмента Model Context Protocol (MCP) в Amazon Quick — это событие доступа, которое может требовать эшелонированной авторизации на уровне инструмента и его параметров, поверх валидного токена. Без гранулярных контролей одна неверно настроенная правами запись способна обойти требования доступа, которые организация должна соблюдать для комплаенса.

Предлагаемый паттерн оценивает claims токена OpenID Connect (OIDC) JSON Web Token (JWT) последовательно, реализуя ролевой и атрибутный контроль доступа на каждом вызове; какие именно контроли включать, заказчик выбирает исходя из своих требований — от разрешений по группам до проверок атрибутов на уровне параметров.

Разрыв между входом и правами описан так: когда MCP-инструменты подключаются к Amazon Quick, валидный single sign-on (SSO) подтверждает, кто вызывает систему, но не то, что ему разрешено делать. MCP при этом — открытый протокол, соединяющий приложения с внутренними инструментами, базами и API и снижающий потребность в собственных интеграциях, однако как только инструменты добираются до чувствительных данных, валидного SSO-токена становится недостаточно. Без эшелонированной авторизации единственный слишком широкий токен открывает инструменты и данные за пределами роли вызывающего, что создаёт риск утечки и усложняет аудит.

Формулировка в публикации предельно короткая: когда организация подключает чувствительные источники данных через MCP, «аутентифицирован» больше не значит «авторизован». Авторизация решает, какие инструменты вызывающий может использовать, откуда и с каким уровнем привилегий, тогда как стандартная проверка идентичности OAuth 2.0 не ограничивает действия на уровне инструмента и параметров.

Четыре шлюза и что именно они проверяют

Технически паттерн реализован одним Lambda-перехватчиком REQUEST, прикреплённым к Amazon Bedrock AgentCore Gateway: он оценивает claims JWT в фиксированной последовательности, и каждый шлюз работает независимо. Шлюзов четыре: проверка MFA, географическое ограничение, сопоставление группы с ролью и проверка прав на инструмент.

Первый шлюз — MFA: его обеспечивает провайдер идентичности, а условие активации задаётся политикой условного доступа. Второй — геозона: claim ctry ограничивает доступ одобренными странами и включается переменной REQUIRE_COUNTRY=true. Третий — ролевой доступ по группам: claim groups сопоставляет членство в группах с политиками читателя, автора или администратора. Четвёртый — права на инструмент: имя запрошенного инструмента проверяется по allowlist выбранной политики.

Шлюзы 3 и 4 — групповой RBAC и права на инструмент — образуют ядро авторизации и активны всегда. Остальные два условны: их можно отключить, выставив переменные окружения в false или вовсе их не задавая, поэтому развёртывание, которому нужны только RBAC и геозона, активирует три шлюза, а более строгий сценарий — все четыре.

Первый шлюз — единственный, который работает вне перехватчика: Microsoft Entra ID применяет политику условного доступа до выпуска токена, поэтому каждый токен, дошедший до шлюза, уже прошёл MFA. Переменная REQUIRE_MFA включает дополнительную проверку claim amr внутри перехватчика — для провайдеров, которые фиксируют факт MFA в токене; два механизма работают вместе, политика не пускает непроверенных вызывающих, а проверка claim подтверждает наличие доказательства прямо в пути запроса.

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

Выдуманный заказчик с реальными требованиями

Разбор построен на вымышленном примере: AnyCompany Global Services — предприятие с мультитенантным реестром рисков на Amazon DynamoDB, доступ к которому идёт через MCP-инструменты в Amazon Quick. Паттерн при этом адресован финансовым организациям, здравоохранению и госсектору, то есть там, где для комплаенс-аудита нужны гранулярные контроли доступа.

Требования AnyCompany перечислены по пунктам: каждый вызов инструмента должен приходить от аутентифицированного вызывающего, прошедшего MFA; вызывающие из неодобренных стран блокируются; ролевые права задают жёсткую границу чтения и записи — читатели могут запрашивать риски, но не создавать, обновлять или удалять их, а администраторы обходят условные шлюзы ради операционной гибкости; и, наконец, каждая мутация обязана порождать неизменяемую запись аудита для комплаенса и форензики.

Что настраивается на стороне Microsoft Entra ID

Провайдером идентичности в разборе выступает Microsoft Entra ID, и требуются две регистрации приложений: ресурсная AnyCompany-MCP-Authorization, которая представляет защищаемый MCP API и чей access token проверяет AgentCore Gateway, и клиентская AnyCompany-Quick-MCP-Client, под которой аутентифицируется Amazon Quick.

У ресурсного приложения Application ID URI задаётся через Microsoft Graph API, поскольку идентификатор — это полный URL, а версия access token выставляется обновлением атрибута requestedAccessTokenVersion до значения 2; оба изменения применяются одним PATCH по Object ID приложения. Для API объявляются четыре делегированных scope — mcp, mcp:stream, stream и invoke, при этом для этого потока достаточно одного делегированного разрешения invoke.

Дальше настраиваются claims: для access token добавляется claim groups в формате Group ID, а также опциональные claims ctry и email. Создаются три группы безопасности — Risk-Register-Readers с доступом только на чтение, Risk-Register-Authors с чтением и записью и Risk-Register-Admins со сверхпользовательским доступом в обход условных шлюзов; после создания из каждой группы копируется Object ID, и перехватчик получает их как переменные READERS_GROUP_ID, AUTHORS_GROUP_ID и ADMINS_GROUP_ID.

Требование MFA задаётся политикой условного доступа, причём политики условного доступа требуют лицензии Microsoft Entra ID P1 или P2, а для проверки нужно подготовить минимум трёх тестовых пользователей с разным членством в группах. Отдельная деталь протокола: Amazon Quick использует Proof Key for Code Exchange (PKCE) и RFC 8707 Resource Indicators — стандарт привязки токенов к конкретным API-эндпоинтам, а вместе они ограничивают каждый access token конкретным MCP-сервером. При обмене токена Amazon Quick отправляет URL AgentCore Gateway как параметр resource, и, поскольку ресурс идентифицируется URL, Entra ID требует представлять клиент и ресурс разными регистрациями приложений.

Как это выглядит на пути запроса

Поток запроса описан пошагово. Amazon Quick аутентифицируется в Entra ID под клиентским приложением, и провайдер перенаправляет вызывающего на свой authorization endpoint, где тот проходит аутентификацию и MFA по требованиям политики условного доступа. Затем Entra ID выпускает токен, ограниченный ресурсным приложением: Amazon Quick обменивает код авторизации на токен-эндпоинте, передавая URL шлюза как параметр resource, и в итоговом JWT уже есть членство в группах и claims страны. Этот JWT Amazon Quick прикладывает как bearer-токен к каждому вызову эндпоинта Amazon Bedrock AgentCore Gateway, а шлюз проверяет подпись, issuer, audience и срок действия токена через JWKS-эндпоинт Entra ID.

Дальше в дело вступает перехватчик: он получает уже проверенные claims и последовательно прогоняет активные шлюзы. Инструментальная Lambda выполняет операцию и пишет данные риска в таблицу fgac-risks в Amazon DynamoDB с партиционными ключами по тенанту и условными выражениями, после чего та же функция добавляет неизменяемую запись аудита, фиксируя личность действующего, действие, время и результат. Ответ возвращается через AgentCore Gateway в Amazon Quick: когда доступ разрешён, слои авторизации невидимы, когда отказано — всплывают понятные сообщения. Шлюз при этом использует авторизатор CUSTOM_JWT, настроенный на три значения из тенанта — issuer, audience (client ID) и JWKS URI, — а провалившийся шлюз возвращает 403 и не вызывает Lambda инструмента.

Шесть инструментов и повторная проверка на стороне функции

Паттерн использует шесть Lambda-функций, по одной на MCP-инструмент. list_risks со списком всех рисков тенанта, get_risk для получения риска по идентификатору и search_risks для поиска по ключевому слову доступны читателям, авторам и администраторам. create_risk, update_risk и delete_risk, то есть создание, изменение и удаление риска, доступны только авторам и администраторам, причём обновление дополнительно проверяет владельца записи.

Ключевое свойство защиты: каждая инструментальная Lambda повторно проверяет права вызывающего на своей стороне, поэтому авторизация сохраняется, даже если перехватчик настроен неверно или обойдён. Каждая мутация добавляет неизменяемую запись аудита с действующим лицом, действием, временем, именем инструмента и результатом в таблицу аудита Amazon DynamoDB.

Проверка персонами и типовые поломки

Проверка описана как вход в Amazon Quick под разными персонами: автор вызывает create_risk, все четыре шлюза проходят, функция записывает риск и запись аудита в DynamoDB, а Amazon Quick получает 200 OK. В сценарии отказа читатель вызывает create_risk, проходит шлюзы с первого по третий и получает отказ на четвёртом, потому что в политике читателей нет прав на записывающие инструменты, — Lambda инструмента при этом не вызывается. Пользователь видит в Amazon Quick понятное сообщение о неудачном действии, привязанное к его уровню доступа.

Подключение выполняется в разделе Home > Connectors > Create for your team > MCP, где для сервис-сервисной аутентификации нужно указать четыре значения: URL MCP-сервера, Client ID, Client Secret и Token URL. В таблице диагностики перечислены характерные симптомы: 401 на каждом запросе означает провал проверки подписи JWT на шлюзе, 403 у пользователя, которому доступ положен, обычно вызван несовпадением Object ID группы между Entra ID и переменными перехватчика, а вход без MFA говорит о том, что политика условного доступа не создана или не нацелена на ресурсное приложение. Для политики MFA дана отдельная рекомендация: создавать её именно на ресурсное приложение, а не на клиентское, и проверять, что состояние политики — «On».

Завершается разбор уборкой ресурсов и общей рамкой применимости: паттерн можно использовать всюду, где MCP-инструменты обращаются к чувствительным ресурсам, направив шлюзы на собственный тенант Entra ID и заменив реестр рисков своим доменом, а число активных шлюзов варьируется — базовая конфигурация может опираться только на claim groups, оставив условные MFA и геозону выключенными, тогда как регулируемая нагрузка включает все проверки.