Что такое безопасность MCP?
Безопасность Model Context Protocol (MCP) – это совокупность мер и практик, направленных на обеспечение целостности, конфиденциальности и корректного функционирования коммуникации между большими языковыми моделями (LLM) и различными инструментами, плагинами, источниками данных и API, с которыми они взаимодействуют. По мере расширения LLM с помощью протоколов, таких как MCP, модели получают способность выполнять действия в реальной среде. Они могут получить доступ к чувствительным данным и вызывать посторонние расширения. Обеспечение защиты таких взаимодействий является критически важным для предотвращения эксплуатации, утечки данных и несанкционированных действий, которые могут быть инициированы моделью или направлены на нее.
Проблемы безопасности MCP выходят за рамки традиционной безопасности приложений. Модели обрабатывают как входящие подсказки от пользователей, так и контекст API инструментов. Это делает их уязвимыми к новым типам атак, таким как инъекции промптов (prompt injection) и манипуляции результатами инструментов. Взаимосвязанный характер MCP создает несколько пределов доверия. Любое слабое звено может повлечь за собой цепочку последствий для безопасности и конфиденциальности. Подход к безопасности должен учитывать не только технические уязвимости. Он также должен включать в себя динамическое и часто непредсказуемое поведение агентов LLM и экосистемы, к которой они подключены.
Вас может также заинтересовать статья «Фреймворки и инструкции по безопасности ИИ».
Основные проблемы и риски для безопасности MCP
Инъекция промпта и отравления инструментов
Инъекция промпта возникает, когда злоумышленники создают специальные входные данные. Они могут быть видимыми для пользователя или скрыты во внешнем контенте. Такие данные манипулируют моделью и вынуждают ее выполнять нежелательные действия. Эти входные данные могут выглядеть безопасными. Однако они разработаны так, чтобы вызвать определенное поведение после интерпретации LLM. Например, злоумышленник может вставить скрытую инструкцию в документ или письмо. После обработки ассистентом такая инструкция может привести к утечке данных или выполнению не планировавшихся системных действий.
Другой опасностью является отравление инструментов (tool poisoning). Оно заключается в изменении метаданных инструментов MCP, в частности, их описаний и параметров. Это делается для ввода модели в заблуждение и выполнения вредных действий. Поскольку инструменты обычно считаются доверенными по умолчанию, незначительные изменения метаданных могут оставаться незамеченными. В то же время, они могут нарушать целостность системы.
Недоверенные серверы
Серверы MCP могут работать локально или быть размещены в облаке. В обоих случаях возникают риски, если сервер скомпрометирован или создан с целью навредить. Злоумышленник может развернуть MCP-сервер, который выглядит легитимным. Позже его инструменты могут быть обновлены так, чтобы производить вредные действия. Например, это может быть доступ к конфиденциальным данным или перенаправление чувствительной информации.
Это также относится к обновлениям серверов. Если поведение инструментов меняется незаметно после установки, агенты или пользователи могут безотчетно запускать опасные операции. Вредоносные серверы могут использовать коллизии названий. В этом случае вводятся обманчивые названия инструментов, имитирующих доверенные функции.
Расширенная поверхность атаки
MCP расширяет поверхность атаки, поскольку подключает LLM ко многим сервисам через API, инструменты и источники данных. Каждая интеграция создает новую потенциальную точку входа для злоумышленников. Если любой подключенный сервис неправильно сконфигурирован или скомпрометирован, он может быть использован для манипуляции моделью, похищения данных или запуска действий в других сервисах.
Такая взаимосвязанность означает, что одна уязвимость может распространяться на другие системы. Это может быть уязвимость в механизмах обработки промптов, логике серверов или метаданных инструментов. Риск увеличивается с ростом количества сервисов, интегрированных в рабочую область модели.
Отсутствие должной авторизации
Некорректная реализация логики авторизации на серверах MCP создает условия для проблемы «запутанного посредника» (confused deputy). В такой ситуации сервер MCP может выполнять действия от имени пользователя с большими привилегиями, чем разрешено. Если сервер неправильно проверяет учетную запись пользователя и права доступа, действия могут выполняться с использованием повышенных привилегий сервера, а не прав пользователя, который делает запрос.
Хотя MCP использует OAuth для авторизации, пробелы в спецификации и отличия в практиках реализации создают уязвимости. Без жесткого контроля доступа модели могут выполнять действия, которые не должны быть разрешены.
Чрезмерные разрешения доступа
Инструменты MCP часто запрашивают широкие области доступа для удобства. Например, может предоставляться полный доступ к Gmail или Drive даже тогда, когда требуются только права чтения. Такие чрезмерные разрешения усугубляют последствия компрометации. Скомпрометированные инструменты могут получать доступ или изменять большие объемы чувствительных данных в разных сервисах.
Кроме внешних угроз, это также создает возможности злоупотребления привилегиями внутренними пользователями или некорректным поведением агентов. Избыточные разрешения могут использоваться нежелательным или несанкционированным способом.
Риски цепочки поставки
Серверы и инструменты MCP состоят из кода и зависимостей. Эти зависимости также могут содержать уязвимости. Злоумышленники могут вставлять вредоносную логику в зависимости или изменять код серверного компонента. В таком случае компрометации испытывают все пользователи этого сервера.
Для уменьшения таких рисков разработчики MCP должны использовать безопасные практики разработки программного обеспечения. К ним относятся статический анализ, анализ состава программного обеспечения, проверка зависимостей и подписанные сборники. Если MCP-сервер разворачивается в облаке, он должен поддерживать криптографическую проверку. Это позволяет клиентам подтверждать его подлинность.
10 ключевых элементов защиты в архитектуре MCP
Защита архитектуры MCP требует контроля каждого предела, где взаимодействуют модели, инструменты, пользователи и внешние системы. MCP создает пути выполнения, сочетающие естественный язык, программный код и привилегированные API. Каждый элемент ниже является точкой контроля. Ошибки на этих этапах могут привести к несанкционированным действиям, утечке данных или компрометации системы.
1. Контроль аутентификации и авторизации
Клиенты и серверы MCP должны взаимно аутентифицироваться и строго проверять OAuth-токены. Токены должны быть ограничены аудиторией, иметь четкие области доступа и выдаваться специально для сервера MCP. Решения по авторизации должны приниматься на стороне сервера, чтобы предотвратить проблему «запутанного посредника» и эскалацию привилегий.
2. Проверка входящих и исходящих данных
Все входящие данные для модели, включая подсказки пользователей и ответы инструментов, должны рассматриваться как недоверенные. Серверы должны проверять и очищать входящие данные для обнаружения инъекций промпта или некорректных структур. Результаты работы модели должны проверяться перед повторным использованием как входящие данные инструментов или контекст для дальнейших операций.
3. Цельность инструментов и метаданных
Определение инструментов, их описания и параметры оказывают непосредственное влияние на поведение модели. Эти артефакты должны быть защищены от изменений посредством подписанных манифестов или доверенных реестров. Любое изменение поведения инструмента или его метаданных должно запускать процедуру проверки и повторной авторизации.
4. Логирование, мониторинг и аудит
Каждый вызов инструмента должен создавать структурированную запись аудита. В записи должны содержаться учетные записи, области доступа, параметры и результаты. Журналы должны быть защищены от изменений и сохраняться централизованно для поддержания реагирования на инциденты. Непрерывный мониторинг позволяет выявлять аномальные или злонамеренные шаблоны использования.
5. Сетевая изоляция и изоляция развертывания
Серверы MCP должны работать в изолированных сегментах сети с минимальным доступом к внутренним сервисам. Компрометация сервера MCP не должна открывать возможности для разветвления атаки. Локальные серверы должны работать в песочнице с ограниченными правами доступа к файловой системе, процессам и сети.
6. Безопасность цепочки поставок и зависимостей
MCP-серверы зависят от посторонних библиотек и инструментов, которые могут изменяться со временем. Зависимости должны проверяться на наличие уязвимостей, фиксироваться по версиям и подтверждаться подписанными сборниками. Конвейеры CI/CD должны быть защищены от инъекции вредоносного кода.
7. Ограничение скорости запросов и предотвращение злоупотреблений
Конечные точки MCP должны ограничивать количество запросов для клиентов, пользователей и инструментов. Такие ограничения уменьшают влияние автоматизированных атак, исследования модели и попыток отказа в обслуживании. Пороги использования должны контролироваться вне зависимости от логики модели.
8. Безопасная передача данных и шифрование
Все коммуникации MCP должны использовать зашифрованные каналы, например TLS. Чувствительные конфигурации, токены и журналы должны шифроваться при хранении. Политики управления ключами и их ротации уменьшают масштаб последствий компрометации.
9. Непрерывное тестирование безопасности
Реализации MCP должны регулярно проверяться с помощью adversarial-промптов, фаззинга и тестирования на проникновение. Проверки должны включать инъекции промпта, неправильное использование инструментов и сценарии обхода авторизации. Тестирование безопасности должно повторяться после обновления инструментов или моделей.
10. Контроль управления и соответствия требованиям
Системы MCP часто обрабатывают регулируемые или чувствительные данные. Требуются четкие политики хранения данных, журналирования доступа и получения согласия пользователей. Управление обеспечивает соответствие поведения MCP правовым, конфиденциальным и организационным требованиям.
Лучшие практики безопасности MCP
1. Ограничение областей разрешений MCP к минимально необходимым действиям
Предоставление широких областей доступа OAuth с самого начала (например, files:* или admin:*) увеличивает последствия компрометации токена. Это также затрудняет отзыв доступа. Вместо этого реализации MCP должны использовать прогрессивную модель областей доступа. Первоначальный набор должен содержать только области с низким уровнем риска, например mcp:tools-basic. Повышенные разрешения следует задавать только при необходимости. Для этого используются целевые вызовы WWW-Authenticate.
Такой подход уменьшает сложность начальной настройки. Он также снижает риск эскалации привилегий и повышает прозрачность аудита. Серверы должны поддерживать токены с ограниченными областями доступа и фиксировать все попытки повышения привилегий. В журналах должны храниться детали областей доступа и корреляционные идентификаторы. Клиенты также должны кэшировать отклоненные области доступа, чтобы предотвратить повторные циклы запросов на повышение привилегий. Не рекомендуется искусственно расширять список scopes_supported, поскольку это приводит к нормализации чрезмерных разрешений и игнорированию запросов на согласие.
2. Обеспечение строгой проверки серверов для всех конечных точек MCP
Серверы MCP не должны передавать токены, если они не были выданы специально для этого сервера. Принятие произвольных токенов доступа (token passthrough) подрывает способность сервера использовать ограничение скорости, проверку запросов и аудит. Это также создает нарушение границ доверия, поскольку подключенные API могут доверять неправильной учетной записи или некорректным предположениям о поведении.
Для предотвращения этого сервер MCP должен:
- проверять, что значения aud (audience) и другие утверждения токена соответствуют его собственной учетной записи;
- отклонять токены, не имеющие областей доступа для сервера MCP;
- не использовать токены повторно между разными сервисами без проверки.
3. Проверка входящих данных как для промптов пользователя, так и для результатов модели
Непроверенные данные создают риски как на входе, так и на выходе взаимодействия MCP. Инъекции промптов могут возникать из-за ввода пользователя или из-за ответов инструментов. Вредоносные данные могут распространяться между контекстами, если результаты модели считаются доверенными.
Для уменьшения риска серверы MCP должны:
- проверять входящие промпты пользователей на наличие известных паттернов инъекций или специальных токенов;
- анализировать результаты инструментов перед повторной передачей их модели или другим системам;
- очищать или отклонять неожиданные ответы, которые могут вызвать нежелательное поведение в следующих компонентах.
4. Логирование всех вызовов инструментов с использованием защищенного хранилища
Надежное журналирование критически важно для обеспечения подотчетности, расследования инцидентов и цифровой экспертизы. Каждый вызов инструмента через сервер MCP должен фиксироваться вместе со связанными метаданными. К таким данным относятся:
- учетная запись клиента MCP и пользователя;
- название инструмента и параметры;
- запрашиваемые области доступа;
- временная метка и результат.
Журналы должны храниться в защищенных системах, устойчивых к переменам. Это могут быть журналы с режимом только добавления или хранилища с одноразовой записью. Такие системы должны поддерживать проверку целостности и контроль доступа. Без надежных журналов становится сложно отслеживать злоупотребления или проводить аудит чувствительных операций.
5. Регулярный аудит установленных инструментов и расширений MCP
Инструменты в среде MCP могут быть изменены после установки. Обновления могут добавлять новое поведение, разрешения или уязвимости. Злоумышленники могут воспользоваться этим, изменяя метаданные инструментов. Это могут быть описания или параметры. Также возможно внедрение вредоносной логики из-за зависимости или динамической конфигурации.
Операторы серверов MCP должны:
- проводить плановые аудиты всех установленных инструментов и расширений;
- повторно проверять задекларированные разрешения и описания на соответствие реальному поведению;
- использовать статический анализ и сканирование зависимостей для выявления изменений или новых рисков;
- фиксировать версии для предотвращения незаметных обновлений;
- отслеживать изменения в реестрах инструментов и генерировать уведомления о неожиданных модификациях.
6. Изоляция серверов MCP от чувствительных внутренних сетей
Серверы MCP не должны разворачиваться в средах с неограниченным доступом к внутренним сервисам. Скомпрометированный сервер может стать точкой входа для более широкого проникновения в сеть.
Для уменьшения риска:
- серверы MCP следует развертывать в изолированных сетевых сегментах со строгим контролем входящего и исходящего трафика;
- локальные серверы MCP должны работать в песочнице с минимальными привилегиями, например с ограниченным доступом к файловой системе и сети;
- необходимо использовать механизмы изоляции платформы, такие как контейнеры, chroot-среды или изолированные среды приложений;
- Для локальных HTTP-каналов необходимо требовать аутентификации или использовать stdio или Unix-domain sockets с ограниченным доступом.
Локальные серверы MCP также должны отображать явные диалоги подтверждения перед выполнением любых команд конфигурации. Диалоговое окно должно отображать полную команду. Оно должно предупреждать о потенциальном риске, например, выполнении rm -rf или curl для эксфильтрации данных. Также обязана быть возможность отменить действие. Такой механизм защищает от непреднамеренного выполнения кода или запуска вредоносных сценариев при старте системы.
