Удалённый MCP-сервер для команды: пользователи, OAuth и права доступа

MAATRIX · 17 октября 2026 · 8 мин чтения

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

«От имени сервера» — технически возможный, но часто неудобный ответ. Менеджеру не нужны все клиентские документы, подрядчику не нужна внутренняя переписка, а увольнение сотрудника не должно требовать замены одного общего ключа у двадцати коллег. Разберём проектирование удалённого MCP на примере внутреннего поиска документов. Предполагается, что базовый MCP-сервис уже работает; здесь мы превращаем его в управляемый командный инструмент.

Три участника вместо одного общего пароля

В схеме участвуют MCP-клиент, сервер авторизации и ваш MCP-сервис. Клиент помогает пользователю войти и получает разрешение. Сервер авторизации, например Keycloak, подтверждает личность и выдаёт токен. MCP-сервис проверяет токен, определяет доступные операции и обращается к документам.

Для удалённых HTTP-подключений MCP описывает механизм на основе OAuth. У локального транспорта stdio другая модель: процесс может получать секреты из окружения. Эти варианты не стоит смешивать, просто открывая в интернет локальный скрипт. Различия зафиксированы в спецификации авторизации MCP.

Токен отвечает на вопрос о полномочиях обращения, но не выполняет всю бизнес-логику. Даже успешно вошедший сотрудник должен получить только разрешённые документы. Поэтому защита складывается из проверки личности, разрешённых операций и ограничения самих данных. Замок на входной двери не объясняет, кому можно открывать сейф в бухгалтерии.

Начинаем с таблицы полномочий

Создайте две тестовые учётные записи и небольшой набор документов. У сотрудника отдела продаж будут собственные материалы и общая инструкция. У технического специалиста — технические документы и та же инструкция. Дополнительно положите контрольный документ, который не должен быть доступен никому из этих двух пользователей.

Опишите операции человеческими словами, затем назначьте им внутренние имена. Для пилота достаточно поиска и чтения. Добавление, удаление и изменение документов пока исключите. Чем меньше инструментов, тем легче доказать, что доступ работает правильно.

Запишите ещё два правила: отсутствие группы означает отсутствие доступа, а неизвестная операция отклоняется. Это спасает от неожиданного наследования прав при добавлении нового инструмента. Проверяйте документ и при поиске, и при чтении по идентификатору. Скрыть его из поисковой выдачи недостаточно, если прямой запрос возвращает содержимое.

Настраиваем сервер авторизации

Если в компании уже есть совместимый сервер идентификации, используйте его после проверки возможностей клиентов. Для отдельного стенда подойдёт Keycloak. Создайте самостоятельную область настроек для проекта, тестовых пользователей и группы. Не стройте рабочую схему на демонстрационной учётной записи администратора.

Для каждого вида MCP-клиента проверьте поддерживаемый способ регистрации: предварительная регистрация, документы метаданных клиента или иной совместимый вариант. В актуальной спецификации есть несколько механизмов; старые инструкции, требующие исключительно динамической регистрации, не универсальны. Сначала определите, какие конкретно приложения команды должны подключаться, затем выберите пересечение их возможностей.

Настройте допустимые redirect URI точно по требованиям клиента. Не ставьте широкий шаблон для всех адресов ради быстрого прохождения теста. Для интерактивного входа используйте подходящий клиенту поток с PKCE. У публичного настольного приложения нельзя считать встроенный секрет надёжно скрытым от владельца компьютера.

Определите разрешения, например documents:read, и аудиторию токена — ваш MCP-ресурс. Названия здесь проектные, а не обязательные значения стандарта. Проверьте, что выбранные claims действительно попадают в выданный access token. Красивое имя группы в административной панели само по себе не сообщает ничего вашему сервису.

Рабочий Keycloak требует HTTPS, постоянной базы данных, корректного hostname и ограниченного административного доступа. Режим start-dev, удобный для локального знакомства, не является готовым размещением для команды. Порядок подготовки описан в руководстве Keycloak для production.

Что должен делать MCP-сервис

Используйте поддерживаемый SDK своей реализации и его механизмы авторизации. Сервис должен публиковать метаданные защищённого ресурса, чтобы совместимый клиент мог найти сервер авторизации. Для обращения без полномочий он возвращает корректный отказ и сведения, необходимые для входа. Подробный пример взаимодействия есть в руководстве MCP по OAuth.

Проверка токена включает его действительность, срок, доверенного издателя и предназначение для вашего ресурса. Для JWT недостаточно декодировать строку и прочитать имя пользователя: подпись нужно проверить доверенной библиотекой с корректными ключами и алгоритмами. Для непрозрачного токена может использоваться introspection. Выбор зависит от вашего сервера авторизации и требований к отзыву доступа.

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

При каждом вызове поиска добавляйте фильтр по разрешённым документам. При чтении документа повторно проверяйте его принадлежность. Если результат кешируется, ключ кеша должен учитывать границы доступа. Иначе первый пользователь честно получит свой ответ, а второй — чужой ответ из быстрого и очень услужливого кеша.

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

Поставьте перед сервисом HTTPS и подключите один MCP-клиент, которым реально пользуется команда. Войдите первой тестовой учётной записью. Проверьте список инструментов, поиск общей инструкции и попытку чтения запрещённого документа. Затем полностью смените пользователя, а не только текст запроса в чате, и повторите испытание.

Для подробного исследования запросов пригодится MCP Inspector. Запускайте его на рабочем компьютере или в закрытом окружении; административный отладчик не нужно публиковать вместе с сервисом. Сначала проверьте транспорт и авторизацию, затем аргументы инструментов и ответы. Точный порядок подключения зависит от используемой версии протокола и SDK.

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

Ошибки, которые не видны на счастливом пути

Нельзя передавать входящий пользовательский токен произвольному внешнему API как универсальный пропуск. У сторонней системы должны быть свои корректно полученные полномочия. Проблема token passthrough и другие риски разобраны в рекомендациях по безопасности MCP.

Не сохраняйте токены в обычных журналах запросов. Для расследования достаточно идентификатора пользователя, инструмента, объекта, результата проверки и корреляционного номера. Текст найденного документа тоже не всегда нужно записывать полностью. Журнал, который содержит все секреты системы, требует не меньше защиты, чем сама система.

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

Добавляем инструменты без расширения доступа по умолчанию

Когда появляется операция записи, заведите для неё отдельное разрешение и согласуйте, кто может его получить. Старый доступ к чтению не должен автоматически превращаться в право менять данные. В самом инструменте проверяйте обязательные поля, допустимые значения и принадлежность объекта пользователю. Описание инструмента помогает модели выбрать действие, но сервер обязан проверять запрос самостоятельно.

Для изменения документа полезно передавать ожидаемую версию записи. Если другой сотрудник уже изменил её, возвращайте конфликт и предлагайте перечитать актуальные данные. Запрос на повторное выполнение связывайте с устойчивым идентификатором операции, чтобы обрыв связи не создавал две записи. Сначала проведите эти проверки на учебных документах. Затем выдавайте права небольшой группе, сохраняя возможность отключить новый инструмент без остановки поиска и чтения.

Конфигурация VPS и ввод в работу

Если MCP-сервис только проверяет доступ и обращается к существующим API, его собственные потребности могут быть небольшими. Но Keycloak и база данных требуют отдельного расчёта. Для общего пилота на одном VPS MAATRIX разумно рассматривать Heka Standard: 4 vCPU, 8 GB RAM и 160 GB диска. Это стенд для измерений, а не гарантия количества сотрудников.

Используйте поддерживаемую Ubuntu или Debian, постоянные тома для базы и отдельные секреты для сервисов. При росте нагрузки или требований к доступности разнесите компоненты. Резервная копия должна включать настройки авторизации и данные, необходимые для восстановления доступа; один архив исходного кода их не заменяет.

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