Автор темы
- MCP в корпоративной архитектуре и новые границы доверия
- Основные сценарии атак на MCP-серверы
- Аутентификация, авторизация и контроль выполнения операций
- Безопасная эксплуатация и мониторинг MCP-интеграций
- Практические рекомендации по внедрению
Протокол контекста модели (Model Context Protocol, MCP) упрощает подключение ИИ-приложений к корпоративным системам, базам данных и внешним сервисам. С его помощью языковая модель получает доступ к инструментам, которые позволяют искать документы, создавать записи, отправлять сообщения и выполнять операции во внутренних системах организации. Такое подключение расширяет возможности автоматизации, но одновременно создает новые пути доступа к корпоративным данным. Результат работы агента теперь зависит от описаний доступных инструментов, содержимого полученных документов, переданных полномочий и правил выполнения операций. Ошибка в любом из этих компонентов может привести к раскрытию информации или выполнению действий от имени пользователя с избыточными правами. Для безопасного внедрения MCP требуется контролировать весь путь от подключения сервера до обработки результата его вызова.
MCP в корпоративной архитектуре и новые границы доверия
MCP представляет собой протокол взаимодействия между ИИ-приложением и внешними источниками данных или инструментами. Его архитектура включает приложение-хост, клиент MCP и один или несколько серверов MCP. Приложение-хост представляет собой среду, в которой работает языковая модель и организуется взаимодействие с пользователем. Клиент MCP отвечает за соединение с сервером, передачу запросов и получение результатов. Сервер MCP предоставляет доступные возможности: инструменты для выполнения операций, ресурсы с данными и шаблоны запросов.
Например, корпоративный ИИ-ассистент может одновременно подключаться к серверу системы управления взаимоотношениями с клиентами (CRM), файловому хранилищу и корпоративной базе знаний. Через первый сервер агент получает сведения о клиентах и сделках, через второй ищет договоры, через третий обращается к внутренним инструкциям. Пользователь формулирует задачу обычным языком, а приложение выбирает подходящие инструменты и передает им параметры.
Взаимодействие с локальными серверами может выполняться через стандартные потоки ввода и вывода (stdio). Такой вариант предполагает запуск серверного процесса на компьютере или рабочей станции, где работает клиент. Удаленные серверы используют потоковую передачу данных по протоколу HTTP (Streamable HTTP). В этом случае обмен сообщениями происходит через сетевое соединение, поэтому дополнительно учитываются защита канала, проверка подлинности удаленной стороны и контроль сетевого доступа.
Подключение MCP-сервера меняет границы доверия внутри корпоративной инфраструктуры. Ранее пользователь мог работать с системой через интерфейс, где набор операций и доступных данных определялся самой системой. При использовании ИИ-агента часть выбора переносится на модель: она анализирует запрос, сопоставляет его с описаниями инструментов и формирует параметры вызова. При этом модель может получать содержимое документов, писем, веб-страниц и ответов других инструментов. Эти данные способны содержать инструкции, которые влияют на дальнейшее поведение агента.
Дополнительная сложность возникает при подключении нескольких серверов. Клиент может передавать модели описания инструментов из разных источников в одном контексте. В результате содержимое одного сервера способно повлиять на выбор инструмента другого сервера. Например, вредоносное описание инструмента поиска документов может содержать указание передавать найденные сведения через инструмент отправки сообщений. Если оба инструмента доступны агенту, появляется возможность межсервисного злоупотребления.
Сам протокол MCP определяет формат взаимодействия и обмена сообщениями. Он не гарантирует корректность бизнес-авторизации операций во всех подключенных системах. Наличие аутентификации на уровне протокола также не означает, что каждый вызов инструмента соответствует полномочиям конкретного пользователя. Эти проверки должны обеспечиваться приложением, сервером MCP и целевой корпоративной системой с учетом их функций.
Основные сценарии атак на MCP-серверы
Один из наиболее характерных сценариев связан с внедрением инструкций через недоверенные данные (prompt injection). Атакующий размещает вредоносный текст в документе, письме, задаче или веб-странице, которые затем анализирует ИИ-агент. Внешне содержимое может выглядеть как обычный рабочий материал, однако внутри него находятся инструкции, рассчитанные на изменение поведения модели. Например, документ с описанием проекта может содержать скрытое указание найти конфиденциальные файлы и передать их через доступный инструмент отправки сообщений.
Опасность такого сценария связана с тем, что модель обрабатывает данные и инструкции в одном контексте. Если приложение недостаточно четко отделяет содержимое внешних источников от доверенных управляющих инструкций, агент может воспринять вредоносный текст как основание для выполнения операции. Проверка только пользовательского запроса не решает проблему: вредоносные инструкции могут поступить через результат вызова инструмента, а затем повлиять на следующий этап работы.
Другой сценарий связан с отравлением инструмента (tool poisoning). Вредоносные инструкции могут находиться в описании инструмента, его параметрах, примерах использования или возвращаемых значениях. При подключении сервера клиент передает модели сведения о доступных инструментах. Если описание содержит скрытые указания, модель может учитывать их при выборе дальнейших действий. Например, инструмент поиска файлов может иметь корректное название и назначение, но его описание дополнено требованием включать содержимое найденных документов в параметры последующего вызова.
Отдельную угрозу представляет подмена инструмента после первоначального одобрения, известная как rug pull. На этапе подключения сервер предоставляет безопасное описание возможностей, проходит проверку и получает разрешение на использование. Позднее владелец или злоумышленник, получивший контроль над сервером, меняет описание инструмента или его фактическое поведение. Пользователь продолжает считать подключение доверенным, хотя условия работы уже изменились. Контроль только при первоначальной установке не выявляет такие изменения. Для обнаружения подмены требуется сравнение текущих определений инструментов с ранее проверенными версиями.
Смежная проблема называется маскировкой инструмента под другой инструмент (tool shadowing). Вредоносный сервер может предоставить описание, похожее на описание уже используемого безопасного инструмента. Модель получает несколько похожих вариантов и при определенных условиях выбирает вредоносный. Риск возрастает, когда в одном контексте объединены инструменты разных серверов, а приложение не показывает пользователю происхождение каждого из них.
Сценарий запутанного посредника (confused deputy) возникает, когда сервер MCP выполняет запрос с использованием собственных полномочий, хотя инициатор операции не имеет соответствующего доступа. Например, сервисная учетная запись MCP-сервера обладает правом читать все документы отдела, а пользователь имеет доступ только к части хранилища. Если сервер не проверяет полномочия пользователя на каждую операцию, агент может получить сведения, недоступные этому пользователю при прямой работе с хранилищем.
Атаки могут затрагивать и цепочку поставки. MCP-сервер часто распространяется как программный пакет или запускаемый компонент с зависимостями. Подмена пакета, компрометация учетной записи разработчика, вредоносная зависимость или ошибка в механизме обновления способны привести к выполнению постороннего кода в инфраструктуре организации. Для локальных серверов последствия могут включать чтение файлов рабочей станции, доступ к переменным окружения и использование сохраненных учетных данных.
Еще один путь атаки связан с утечкой токенов и других секретов. Учетные данные могут попасть в контекст модели, журнал вызовов, сообщения об ошибках или параметры инструмента. Если сервер передает полученный токен следующему сервису без проверки его назначения, возникает риск использования полномочий в другом контексте. Особенно опасны долгоживущие токены с широким набором разрешений. Компрометация одного компонента в таком случае может открыть доступ к нескольким корпоративным системам.
Аутентификация, авторизация и контроль выполнения операций
Аутентификация подтверждает личность пользователя или компонента, который устанавливает соединение. Авторизация определяет, какие действия разрешены этому субъекту. Для MCP эти механизмы должны работать на нескольких уровнях: при подключении клиента к серверу, при обращении сервера к корпоративной системе и непосредственно перед выполнением операции.
Для удаленных серверов MCP спецификация предусматривает применение механизмов авторизации на основе протокола OAuth. OAuth представляет собой открытый протокол делегированной авторизации, позволяющий приложению получать ограниченный доступ к ресурсу от имени пользователя. В актуальных требованиях к авторизации MCP используются механизмы, связанные с OAuth 2.1, включая указание целевого ресурса и проверку назначения токена.
Клиент должен запрашивать токен для конкретного сервера, а сервер обязан проверять, что полученный токен предназначен именно ему. Для этого применяется привязка токена к целевой аудитории. Проверка не позволяет использовать учетные данные, выданные для одного сервиса, в другом сервисе без соответствующего разрешения. Передача клиентского токена в нижележащую систему без проверки назначения запрещена требованиями безопасности MCP. Если серверу требуется обратиться к внешнему API (программному интерфейсу приложения), для такого обращения должен использоваться отдельный токен, выданный для целевого сервиса.
При авторизации через перенаправление требуется защита от перехвата кода авторизации. Для этого используется PKCE — механизм подтверждения владения проверочным кодом. Клиент создает секретное значение и связанную с ним проверочную строку, а при обмене кода авторизации подтверждает, что запрос выполняет исходный инициатор. Также необходима точная проверка адресов перенаправления. Подмена такого адреса может направить пользователя на контролируемый атакующим ресурс.
При локальном подключении через stdio модель авторизации отличается от сетевого сценария. Доступ к серверу может зависеть от учетной записи операционной системы, окружения запуска процесса и переданных ему учетных данных. Поэтому безопасность определяется правами процесса, разрешениями на чтение файлов, доступом к сети и возможностью взаимодействовать с другими приложениями. Запуск локального сервера от имени пользователя с административными правами без обоснованной необходимости существенно увеличивает последствия компрометации.
Проверка полномочий должна учитывать не только доступность инструмента, но и конкретную операцию. Например, возможность просматривать карточку клиента не должна автоматически давать право изменять ее, удалять запись или выгружать всю клиентскую базу. Для этого применяются отдельные разрешения на чтение, создание, изменение и удаление данных. Если операция затрагивает критичные сведения или приводит к необратимому результату, требуется дополнительное подтверждение пользователя либо согласование по установленному процессу.
Важное значение имеет проверка параметров вызова. Сервер должен контролировать типы данных, допустимые значения, длину строк, идентификаторы объектов и дополнительные поля. Для структурированных параметров применяются строгие схемы проверки, исключающие передачу неизвестных полей. Однако корректный формат запроса сам по себе не подтверждает его допустимость. Например, идентификатор документа может соответствовать формату, но у пользователя все равно может отсутствовать право на его чтение.
Контроль выполнения операций должен находиться в доверенном программном компоненте. Языковая модель может предложить действие, но окончательное решение о его допустимости принимает сервер или шлюз политик доступа. Такой компонент проверяет пользователя, целевой ресурс, тип операции, параметры, ограничения и необходимость дополнительного подтверждения. Проверка проводится при каждом вызове, поскольку полномочия пользователя или состояние ресурса могут измениться после начала диалога.
Безопасная эксплуатация и мониторинг MCP-интеграций
Безопасность MCP-сервера зависит от условий его эксплуатации. Даже корректная реализация протокола может стать источником инцидента при чрезмерных правах процесса, небезопасном хранении секретов или отсутствии контроля изменений. Поэтому сервер должен рассматриваться как отдельный компонент корпоративной инфраструктуры со своим владельцем, перечнем зависимостей, настройками доступа и журналом эксплуатации.
Локальные серверы целесообразно запускать в изолированной среде с ограниченным доступом к файловой системе и сети. Доступ к каталогам должен соответствовать назначению инструмента. Например, серверу поиска документов требуется чтение определенного каталога, но не полный доступ к домашней директории пользователя. Если сетевое взаимодействие не требуется, исходящие соединения должны быть ограничены. Запуск процесса от отдельной учетной записи снижает последствия возможной компрометации.
Удаленные серверы должны использовать защищенный канал связи на основе HTTPS. Защиту соединения обеспечивает протокол TLS, который поддерживает шифрование передаваемых данных и проверку подлинности сервера. Сертификаты и параметры соединения требуют регулярного контроля. Внутренние сетевые ограничения должны исключать доступ MCP-сервера к адресам и сервисам, не связанным с его назначением. Это особенно важно для защиты от обращений к внутренним ресурсам через уязвимые функции загрузки содержимого или обработки пользовательских адресов.
Отдельный контроль требуется для описаний инструментов. При первоначальном подключении фиксируются названия, описания, схемы параметров и возвращаемых данных, а также служебные признаки, влияющие на отображение и подтверждение операций. Проверенная версия может храниться в виде контрольной суммы. При изменении определения инструмента система сравнивает новую версию с утвержденной и направляет изменение на повторную проверку. Такой механизм позволяет обнаруживать подмену описания, хотя сам по себе не гарантирует неизменность программного кода или фактического поведения сервера.
Мониторинг должен охватывать каждый вызов инструмента. В журнале фиксируются идентификатор пользователя, сервер-источник, название инструмента, время обращения, тип операции, результат проверки полномочий и итог выполнения. Для расследования также важны сведения о версии определения инструмента и идентификаторе сессии. Содержимое параметров журналируется с учетом классификации данных: секреты, токены, пароли и персональные данные не должны попадать в открытые журналы.
Журналы MCP-интеграций целесообразно передавать в централизованную систему управления событиями информационной безопасности (SIEM). Это позволяет сопоставлять вызовы инструментов с событиями целевых систем и действиями учетных записей. Например, необычная последовательность запросов к файловому хранилищу может быть сопоставлена с последующей отправкой большого объема данных через почтовый сервис. Отдельного внимания требуют новые инструменты, резкое увеличение частоты вызовов, обращения к административным функциям и попытки доступа к объектам вне обычной области работы пользователя.
Для реагирования необходим механизм оперативного отключения интеграции. Он должен блокировать выполнение новых операций на уровне шлюза или оркестратора, даже если агент продолжает формировать запросы. При обнаружении компрометации сервера могут потребоваться отзыв токенов, остановка процесса, блокировка сетевых соединений и проверка действий, выполненных с момента последнего доверенного состояния. Восстановление подключения допустимо после проверки программного компонента, его зависимостей и определений инструментов.
Практические рекомендации по внедрению
Подготовка MCP-интеграции начинается с инвентаризации. Для каждого сервера фиксируются владелец, источник поставки, версия, способ запуска, сетевые адреса, зависимости и подключенные корпоративные системы. В реестре также отражаются доступные инструменты, типы обрабатываемых данных и операции, которые сервер способен выполнять. Без такого перечня организация не сможет определить фактическую область доступа и установить ответственных за эксплуатацию.
До подключения к рабочим системам требуется моделирование угроз. В него входят сценарии внедрения инструкций через документы и ответы инструментов, подмены определений, межсерверного влияния, утечки токенов, повторного выполнения операций и использования избыточных полномочий. Для каждого сценария определяются исходные условия, затрагиваемые ресурсы, возможные последствия и контрольные меры. Отдельно оцениваются действия, которые агент способен выполнять без участия пользователя, и операции, требующие подтверждения.
Проверка поставки охватывает происхождение программного пакета, репозиторий, издателя, цифровую подпись или контрольную сумму, состав зависимостей и историю обновлений. Использование публичного пакета без проверки исходного кода и его происхождения создает риск установки вредоносного компонента. Для корпоративного применения предпочтительны утвержденные версии, прошедшие проверку в тестовой среде. Изменения в зависимостях и описаниях инструментов должны попадать в процесс управления изменениями.
Настройка доступа выполняется с учетом минимально необходимых полномочий. Для каждого сервера предусматриваются отдельные учетные данные и ограниченные разрешения. Сервисные учетные записи не должны иметь административный доступ ко всем подключенным системам. Если инструмент предназначен для чтения документов, его полномочия не должны включать изменение или удаление файлов. Если операция требует доступа к персональным данным, область такого доступа должна соответствовать назначению задачи и правам пользователя.
Перед вводом в эксплуатацию проводятся испытания. Проверяются прямое и косвенное внедрение инструкций, подмена источника данных, изменение описания инструмента, некорректные параметры вызова, повторное использование токена, обращение к соседним ресурсам и попытки выполнения запрещенных операций. Отдельно тестируются отказ одного из сервисов и цепочки вызовов нескольких инструментов. Результатом испытаний должны быть подтвержденные сведения о том, какие действия система разрешает, какие блокирует и какие события регистрирует.
Приемка интеграции предполагает проверку не только штатного сценария, но и отказных ситуаций. Например, при недоступности сервиса авторизации выполнение защищенных операций должно прекращаться. При изменении определения инструмента без повторного согласования вызов должен блокироваться или переводиться в режим проверки. При обнаружении подозрительной активности должна существовать возможность быстро отключить сервер и отозвать его учетные данные. Эти условия фиксируются в критериях приемки и проверяются до предоставления доступа к рабочим данным.
После запуска требуется регулярное сопровождение. Оно включает контроль обновлений, пересмотр разрешений, проверку журналов, анализ изменений инструментов и повторное тестирование после существенных изменений. Периодичность проверок зависит от критичности подключенных систем и характера обрабатываемых данных. Для серверов с возможностью изменения финансовых, кадровых или клиентских записей контроль должен быть строже, чем для инструментов, выполняющих только поиск общедоступных внутренних материалов.
Ответственность за интеграцию распределяется между владельцем бизнес-системы, командой ИБ, разработчиками и эксплуатацией. Владелец системы определяет допустимые операции и категории данных. Разработчики отвечают за корректность реализации и проверки параметров. Эксплуатация контролирует конфигурацию, обновления и доступность. Команда ИБ оценивает угрозы, требования к авторизации, журналированию и реагированию. Такое распределение исключает ситуацию, при которой подключение сервера одобрено технически, но никто не отвечает за допустимость его действий с корпоративными данными.
MCP-интеграции расширяют доступ ИИ-агентов к корпоративным системам и одновременно добавляют новые точки контроля. Основные риски связаны с обработкой недоверенных инструкций, изменением определений инструментов, избыточными полномочиями и передачей учетных данных между сервисами. Безопасность такой архитектуры требует проверки каждого вызова на уровне доверенного программного компонента, изоляции серверов и постоянного контроля изменений. Подключение MCP-сервера к рабочим данным должно проходить через инвентаризацию, моделирование угроз, испытания и формальную приемку.
