Управление серверами MCP: от заявки до вывода из эксплуатации
Ведите перечень серверов MCP, одобряйте серверы до начала использования, проверяйте каждый инструмент, считайте измененные определения поводом для новых решений и аккуратно выводите серверы из эксплуатации.
Коротко о решении
Управление серверами MCP рассматривает каждый сервер как ПО, которое может действовать в корпоративных системах. Ведите перечень, в котором у каждого сервера есть владелец, одобряйте серверы по четким критериям, проверяйте каждый инструмент, а не только сервер в целом, считайте изменение определения инструмента поводом для нового решения, изолируйте серверы, работающие на ноутбуках, и выводите серверы из эксплуатации, не только удаляя их конфигурацию, но и отзывая учетные данные. Наличие в реестре или успешное сканирование дают информацию для этих решений, но не принимают их за вас.
Что охватывает управление серверами MCP
Сервер MCP — это та часть агентной системы, которая выполняет работу. Он предоставляет инструменты, например для создания задачи или запроса к базе данных, и выполняет их с теми учетными данными и правами доступа, которые у него есть. Одни серверы работают удаленно и доступны по HTTP, другие — это локальные процессы, запущенные на ноутбуке пользователя.
Управление серверами MCP определяет, какими из этих серверов могут пользоваться ваши команды, и поддерживает это решение в актуальном состоянии. Оно следует жизненному циклу: выявить то, что уже есть, одобрить серверы по критериям, проверить их инструменты, отслеживать изменения и выводить серверы из эксплуатации, когда они больше не нужны. Для каждого этапа нужны ответственный и запись.
Рядом с ним находится управление правами доступа, которое определяет, кто может использовать одобренный сервер и с какими данными. Управление серверами обычно идет первым: мало смысла управлять доступом к серверу, которому вы еще не решили доверять. OWASP MCP Top 10 — сейчас это проект в стадии бета-версии — относит к рискам атаки на цепочку поставок, отравление инструментов и теневые серверы MCP.
Составьте перечень, который можно поддерживать в актуальном состоянии
Серверы MCP часто начинают использовать до того, как их кто-либо одобрит; рекомендации проекта MCP советуют администраторам исходить из того, что их не спросят заранее. Начните с перечня того, что уже есть: удаленные серверы, подключенные через шлюз или административные настройки ИИ-клиента, и локальные серверы в конфигурационных файлах таких инструментов, как Claude Code и Cursor.
Конфигурационные файлы клиентов хранятся в известных местах, поэтому средства управления конечными устройствами могут постоянно их собирать. Инвентаризация устройств показывает, что настроено, а это не то же самое, что подключено или используется. Считайте ее отправной точкой для разговора, а не доказательством.
Записывайте о каждом сервере достаточно сведений, чтобы впоследствии быстро принимать решения.
| Поле | Почему это важно |
|---|---|
| Владелец | Есть человек, который одобряет изменения и отвечает на вопросы |
| Издатель и источник | Показывает, кому вы доверяете и откуда приходят обновления |
| Версия или конечная точка | Позволяет замечать изменения и реагировать на бюллетени безопасности |
| Где работает | Локальным серверам нужны средства контроля на конечных устройствах; для удаленных можно использовать шлюз |
| Учетные данные и области действия (scopes) | Показывает, что сервер может делать с чьими-то полномочиями |
| Включенные инструменты | Показывает, что агенты на самом деле могут поручить серверу |
| Пользователи и команды | Показывает, кого затронет изменение или вывод из эксплуатации |
| Дата следующего пересмотра | Не позволяет одобрению по умолчанию стать бессрочным |
Одобряйте серверы по четким критериям
Короткий опубликованный набор критериев делает одобрение быстрее и единообразнее. Рекомендации проекта MCP для организаций предлагают список разрешенных проверенных серверов с закрепленными версиями, а также такие критерии, как идентифицируемый издатель, доступный для чтения исходный код, метаданные о происхождении и перечень компонентов ПО (SBOM).
Реестры помогают находить серверы, но не одобрять их. Официальный реестр MCP (MCP Registry), который пока доступен в предварительной версии, проверяет, что издатель контролирует пространство имен, а сканирование безопасности оставляет реестрам пакетов и производным каталогам. По словам самого проекта, наличие в реестре не означает рекомендации. Эти вопросы охватывают большинство решений об одобрении:
- Кто издает сервер и можно ли прочитать его исходный код?
- Нужно ли запускать его локально или есть удаленная версия?
- Как он проходит аутентификацию и чьи учетные данные будет использовать?
- Какие области действия он запрашивает и самые ли они узкие из достаточных для работы?
- Какие инструменты он предлагает и какие из них изменяют данные или связываются с людьми?
- Какие данные он будет читать и куда попадут результаты?
- Как выпускаются обновления и как вы узнаете об уязвимостях?
Для общих систем выбирайте удаленные серверы
Серверу, который лишь служит оберткой над API SaaS-сервиса, запуск на каждом ноутбуке ничего не дает. Рекомендации MCP советуют использовать удаленную версию, если она есть: она не выполняет код на компьютере пользователя, использует предусмотренный протоколом процесс авторизации вместо токена в локальном файле и обновляется в одном месте.
Кроме того, к удаленным серверам можно обращаться по управляемому пути, где к каждому запросу применяются правила доступа и ведутся записи. Оставляйте локальные серверы для задач, которым действительно нужен локальный компьютер, например для чтения рабочего дерева репозитория или управления локальным инструментом.
Проверяйте каждый инструмент, а не только сервер
Одобрить сервер — не то же самое, что одобрить все, что он умеет. Сервер системы управления проектами может предлагать инструменты для чтения, редактирования и удаления задач, а также для изменения прав доступа. Включайте инструменты, которые нужны рабочему процессу, а остальные оставляйте выключенными.
Читайте не только документацию, но и определения инструментов. Названия и описания инструментов — это инструкции, которые читает модель, и вредоносный сервер может спрятать в них указания. Invariant Labs назвала это отравлением инструментов (tool poisoning), когда продемонстрировала такую атаку в апреле 2025 года. Согласно спецификации MCP, клиенты должны считать аннотации инструментов — например, подсказку о том, что инструмент только читает данные, — недоверенными, если только сервер не является доверенным.
Кроме того, список инструментов может зависеть от того, кто обращается. Текущая спецификация позволяет серверу возвращать разные инструменты в зависимости от авторизации, предъявленной в запросе, поэтому проверяйте инструменты, которые фактически видит каждая роль.
Считайте изменения поводом для новых решений
Сервер может изменить определения своих инструментов после того, как вы его одобрили; это иногда называют подменой после одобрения («rug pull»). Протокол не требует, чтобы клиенты повторно запрашивали подтверждение при изменении определения, поэтому защиту должны обеспечивать ваш клиент, шлюз или процесс.
Закрепляйте то, что одобрили. Для локальных пакетов закрепляйте версию; при запуске через такие средства, как npx или uvx, это фиксирует только пакет верхнего уровня, тогда как образ контейнера, закрепленный по дайджесту, фиксирует все дерево зависимостей. Для инструментов записывайте проверенные определения и не пропускайте измененные, пока их кто-нибудь не проверит.
Изменения на вашей стороне тоже имеют значение. Новые области действия, новая команда или новая среда, например рабочая, — это повод заново рассмотреть одобрение, а не молча его расширить.
Изолируйте серверы, работающие локально
Локальный сервер — обычный процесс с привилегиями пользователя. Он может читать файлы и переменные окружения, доступные этому пользователю, и подключаться к любым узлам сети. Проект MCP называет изоляцию процессов самой действенной мерой снижения риска.
Задайте базовые правила по умолчанию, а не оставляйте это на усмотрение каждого: запускайте сторонние серверы в контейнере, не монтируя ничего сверх необходимого, выдавайте каждому серверу только его собственные учетные данные с узкой областью действия, ограничивайте доступ к файловой системе и исходящие подключения. Клиенты, которые предлагают установку в один клик, должны показывать точную команду до ее выполнения.
Записывайте каждое одобрение
Одобрение, которое существует только в ветке чата, потом трудно проверить. Короткая запись делает решение явным и дает следующему проверяющему основу для сверки. Пример ниже условный.
Храните запись вместе с соответствующей позицией в перечне и обновляйте ее при каждом изменении сервера, его инструментов или учетных данных.
| Поле | Пример |
|---|---|
| Сервер | Трекер задач, удаленный сервер на стороне поставщика |
| Владелец | Руководитель платформенной разработки |
| Одобрено для | Инженерные команды, рабочая среда |
| Включенные инструменты | Поиск задач, чтение задачи, создание задачи |
| Не включены | Удаление задачи, изменение прав доступа к проекту |
| Полномочия | Собственное разрешение OAuth каждого пользователя, ограниченное областями действия для задач |
| Условия | Создание задач проходит проверку в течение первого месяца |
| Следующий пересмотр | Через три месяца или раньше, если изменятся инструменты или области действия |
Аккуратно выводите серверы из эксплуатации
Вывести сервер из эксплуатации — значит не просто удалить запись в конфигурации. Закройте доступ всем, кто им пользовался, отзовите учетные данные, которые у него были, и по возможности удалите локальные конфигурации. Рекомендации MCP советуют при удалении сервера выполнить ротацию всего, что у него хранилось.
Сохраняйте историю. Записи о действиях сервера остаются полезными для расследований и после его удаления, а выведенный из эксплуатации сервер, который снова появился в перечне, следует рассматривать как новый запрос.
Где подходит Durin
Durin переводит удаленные серверы MCP на единый управляемый путь. Участники могут запросить подключение из каталога или предложить собственный сервер, указав его адрес и назначение, а администратор одобряет или отклоняет запрос. Само по себе одобрение ничего не активирует: после него все равно следуют настройка провайдера, проверка инструментов, тест в режиме только для чтения и активация.
Каждый инструмент проверяется до того, как им можно будет пользоваться, в том числе на то, читает он данные или изменяет их и к каким ресурсам может обращаться. Непроверенные инструменты остаются заблокированными. Если сервер меняет определение инструмента, измененный инструмент требует новой проверки, а ранее выданные для него одобрения отзываются. Администраторы могут ограничить подключение определенными командами или отключить установку, сохранив ее конфигурацию и историю.
Для серверов за пределами Durin функция обнаружения теневых MCP (Shadow MCP) собирает отчеты о серверах MCP, настроенных на зарегистрированных устройствах. Отчеты — это наблюдения, а не доказательство текущего подключения, и статус проверки не блокирует доступ. Чтобы взять обнаруженный сервер под управление, добавьте его в разделе «Подключения» и переключите клиенты на Durin.