Шлюз MCP и безопасность MCP: что берет на себя шлюз
Шлюз проверяет доступ и записывает получаемые им запросы агентов. Узнайте, какие риски безопасности MCP он закрывает, а для каких по-прежнему нужны другие средства контроля.
Коротко о решении
Шлюз для MCP — это контрольная точка на пути между ИИ-клиентами и инструментами, которыми они пользуются. Для получаемых запросов он может проверять, кто обращается, применять правила доступа, хранить учетные данные раздельно, не пропускать непроверенные инструменты, направлять рискованные изменения на проверку и записывать, что произошло. Безопасность MCP — задача шире: она охватывает также промпт-инъекции, код каждого сервера, локальные серверы на ноутбуках и все маршруты в обход шлюза. Большинству команд нужны и шлюз, и эти другие средства контроля одновременно.
Короткий ответ
Протокол MCP (Model Context Protocol) связывает ИИ-клиенты, такие как Claude Code или Cursor, с серверами, которые предоставляют инструменты: поиск в очереди заявок, чтение файла, обновление записи о клиенте. Шлюз располагается между этими клиентами и серверами. Клиенты подключаются к одной управляемой конечной точке, а шлюз проверяет каждый запрос, прежде чем передать его дальше.
Безопасность MCP — понятие более широкое. Она охватывает все случаи, когда использование инструментов агентом может пойти не так: модель следует инструкциям, скрытым в содержимом; инструменты сервера оказываются не тем, за что себя выдают; токен используется там, где не должен; у агента больше доступа, чем нужно для его задачи; или существует подключение, о котором никто не знал.
Поэтому сравнение касается не столько двух продуктов, сколько охвата. Шлюз — одно из средств контроля в рамках безопасности MCP, причем сильное в отношении тех запросов, которые он получает. Вопрос в том, какие риски он закрывает в вашем развертывании и кто отвечает за остальные.
Где закрывается каждый риск безопасности MCP
Хороший исходный перечень дают два источника. Лучшие практики безопасности MCP описывают атаки, характерные именно для протокола, например сквозную передачу токенов (token passthrough) и проблемы «запутавшегося заместителя» (confused deputy). OWASP MCP Top 10 — на момент написания проект в стадии бета-версии — объединяет основные риски в десять категорий.
В таблице для каждой из этих десяти категорий показано, чем может помочь шлюз и что должно обеспечиваться другими средствами. Это отправная точка для вашей собственной проверки, а не описание какого-либо конкретного продукта, поэтому просите продемонстрировать каждую строку, на которую вы полагаетесь.
| Риск | Что может сделать шлюз | Что еще нужно |
|---|---|---|
| Ненадлежащее управление токенами и раскрытие секретов | Не допускать попадания учетных данных вышестоящих систем на устройства и в промпты, хотя из-за этого сам шлюз становится ценной целью | Хранилища секретов и короткоживущие токены с узкой областью действия |
| Повышение привилегий из-за постепенного расширения прав (scope creep) | Ограничивать инструменты, ресурсы и действия для каждой команды и проверять новый доступ | Узкие области действия OAuth (scopes) и регулярный пересмотр доступа |
| Отравление инструментов | Блокировать инструменты до проверки и отправлять измененные определения на новую проверку | Проверка серверов до одобрения и клиенты, которые сообщают об изменениях |
| Атаки на цепочку поставок и подмена зависимостей | Немногое: он не может проверить код сервера, а может лишь ограничить, какие серверы подключены | Проверка происхождения, закрепленные версии и перечни компонентов ПО (SBOM) |
| Внедрение и выполнение команд | Частично: он может отклонять аргументы, выходящие за рамки проверенной схемы | Проверка входных данных и безопасная обработка команд на сервере, а также изоляция в песочнице |
| Промпт-инъекции через содержимое, которое читает агент | Ограничивать то, до чего может добраться введенный в заблуждение агент, и задерживать значимые изменения до проверки | Защита на уровне модели и клиента и запросы подтверждения |
| Недостаточная аутентификация и авторизация | Проверять личность и права доступа в каждом получаемом запросе | Каждый сервер по-прежнему применяет собственный контроль доступа |
| Отсутствие аудита и телеметрии | Записывать решения и результаты для проходящих через него запросов | Журналы клиентов, серверов и конечных устройств для всего остального |
| Теневые серверы MCP | Ничего — для запросов, которые до него не доходят | Обнаружение, инвентаризация конечных устройств, сетевые средства контроля и простой официальный путь |
| Внедрение в контекст и избыточное раскрытие данных | Ограничивать то, что могут читать инструменты, и анализировать ответы, если это настроено | Классификация данных и условия обработки данных у провайдера модели |
С чем шлюз справляется хорошо
Ценность шлюза в том, что каждый полученный им запрос проходит одни и те же проверки, какой бы клиент его ни отправил. Шлюз может подтвердить, кто обращается, состоит ли этот человек по-прежнему в команде и вправе ли он использовать данное подключение, инструмент и ресурс. Эти решения сосредоточены в одном месте, а не повторяются — причем непоследовательно — в каждом клиенте и сервере.
Шлюз может разделять учетные данные. Пользователи входят в шлюз, а шлюз обращается к вышестоящей системе с учетными данными, выданными именно для нее. Спецификация MCP запрещает напрямую передавать токен клиента дальше, потому что так обходятся средства контроля вышестоящей системы и не остается четкой записи о том, кто выполнил действие.
Шлюз может рассматривать инструменты как объекты проверки. Названия и описания инструментов — это текст, который модель читает и на основе которого действует. Поэтому шлюз, который не пропускает непроверенные инструменты и отправляет измененное определение на новую проверку, закрывает пробел, оставленный протоколом. Он также может направлять рискованные изменения проверяющему и записывать как решение, так и результат.
У шлюза есть собственные обязанности в области безопасности
Шлюз концентрирует доступ, поэтому заслуживает такой же тщательной проверки, как любая система, которая хранит учетные данные для множества других систем. В лучших практиках безопасности MCP сервер, связывающий клиентов со сторонними API, называется прокси-сервером, и на него возлагаются особые обязательства.
Такой прокси должен запрашивать согласие для каждого клиента перед перенаправлением на сторонний сервер авторизации, требовать точного совпадения адресов перенаправления и проверять параметр OAuth state. Без этих мер злоумышленник может воспользоваться ранее данным согласием пользователя и получить доступ, который пользователь никогда не предоставлял. Спецификация называет это атакой «запутавшегося заместителя» (confused deputy).
Кроме того, шлюз получает метаданные и обращается к вышестоящим серверам от имени пользователей. Спецификация ожидает, что клиенты, развернутые на серверах, будут защищаться от подделки серверных запросов (SSRF): например, требовать HTTPS, блокировать частные диапазоны адресов и проверять перенаправления. Уточните, как шлюз обрабатывает эти сценарии и что произойдет с хранящимися в нем учетными данными, если он будет скомпрометирован.
Что остается за пределами шлюза
Шлюз видит запросы, но не рассуждения, которые за ними стоят. Если документ велит модели куда-то отправить данные, а сам запрос — из тех, что этому человеку разрешено выполнять, одна лишь проверка политики не отличит намерение от инструкции. Anthropic называет промпт-инъекции проблемой, которая еще далека от решения. Узкие права доступа и проверка значимых действий ограничивают ущерб, но не делают содержимое заслуживающим доверия.
За пределами шлюза остаются и локальные серверы. Сервер, запущенный на ноутбуке, работает с привилегиями пользователя, а его трафик никогда не доходит до удаленного шлюза. В рекомендациях проекта MCP такие серверы рассматриваются как обычное ПО, которому нужны контроль на конечных устройствах и управление программным обеспечением.
Аннотации инструментов, например подсказка о том, что инструмент только читает данные, тоже не являются средством принудительного контроля. Разработчики MCP рекомендуют обеспечивать гарантии безопасности с помощью детерминированных средств контроля. Наконец, правила шлюза не действуют, когда те же учетные данные используются по другому маршруту, и шлюз не видит, что клиент отправляет своему провайдеру модели.
Пример: заявка в поддержку со скрытыми инструкциями
Рассмотрим условный пример: агент поддержки читает заявки и может искать записи о клиентах. Приходит заявка с текстом, который велит агенту экспортировать полный список клиентов и приложить его к ответу.
Модель может выполнить эту инструкцию, а может и нет — это зависит от модели и клиента. Если она попытается, шлюз проверит, вправе ли этот человек применять инструмент экспорта к этому ресурсу. Если инструмент для поддержки никогда не включали, запрос будет отклонен. Если его включили, а команда требует проверки экспорта, проверяющий увидит точный запрос до того, как что-либо будет выполнено.
Если экспорт разрешен и не требует проверки, шлюзу нечего возразить: запрос разрешен заданными ему правилами. Поэтому устройство инструментов и решения о доступе важны не меньше, чем сама контрольная точка.
Как с этим сочетаются инструменты безопасности MCP
Продукты, которые продаются как решения для безопасности MCP, часто выполняют иные задачи, чем шлюз. Сканеры проверяют пакеты серверов и описания инструментов на скрытые инструкции до того, как вы их одобрите. Средства мониторинга во время выполнения анализируют содержимое и поведение в процессе работы агентов. Средства обнаружения ищут серверы MCP, настроенные на устройствах.
Они дополняют шлюз, а не заменяют его. Сканирование помогает решить, какие серверы одобрять, анализ добавляет проверку содержимого, которую не может обеспечить одна лишь политика, а обнаружение показывает, какие маршруты по-прежнему обходят ваши средства контроля. При оценке шлюза эти вопросы помогут понять, что именно он обеспечивает в вашем развертывании:
- Какие запросы шлюз действительно будет видеть, а какие маршруты его обходят?
- Как разделены вход клиента и учетные данные для вышестоящих систем?
- Как проверяются определения инструментов и что происходит, когда одно из них меняется?
- Можно ли ограничивать доступ по инструменту, ресурсу и типу действия, а не только по подключению?
- Как устроена проверка предлагаемого изменения и что видит проверяющий?
- Разделяет ли запись решение о доступе и результат действия?
Где подходит Durin
Durin обеспечивает управление доступом через MCP с помощью шлюза — для команд, которым нужны единые правила и доказательная база по запросам агентов. Каждый вызов, проходящий через шлюз, должен пройти актуальные проверки: личность, членство, команда, подключение, учетные данные, проверенный инструмент, ресурс и анализ содержимого. Инструменты остаются заблокированными до проверки, а измененное определение инструмента требует новой проверки. Durin обращается к провайдеру с учетными данными самого подключения и не передает собственный токен в вышестоящую систему.
По умолчанию проверенные запросы могут выполняться после этих проверок. Команды могут по умолчанию запрещать доступ или требовать, чтобы предлагаемые изменения проверял другой администратор; затем инициатор запроса отправляет тот же запрос повторно до истечения срока действия разрешения. Durin записывает решение и результат по отдельности, а действие с неопределенным результатом никогда не повторяется автоматически.
Durin не предотвращает промпт-инъекции и не может управлять запросами, которые идут в обход него. Его функция обнаружения теневых MCP (Shadow MCP) сообщает о серверах MCP, настроенных на зарегистрированных устройствах: это помогает найти такие маршруты, но не блокирует их. Средства контроля на уровне модели, клиента, конечных устройств и серверов по-прежнему остаются частью плана.