Ваш MCP-сервер защищен. А вот лежащая в его основе бухгалтерская система — нет.

В недавней статье на Unite.AI Гил Фейг изложил шесть рекомендаций по созданию защищенного MCP-сервера. Они разумны, и всем, кто выпускает MCP-сервер, следует им следовать. Его совет предоставить каждой интеграции «собственную детально настроенную роль, строго ограниченную необходимыми разрешениями» совершенно верен. Но он также предполагает, что система на другом конце соединения поддерживает детально настроенные роли. За этим стоит более широкое предположение, о котором редко говорят прямо: системы, к которым обращается сервер, можно защитить на том же уровне.

В корпоративном программном обеспечении это часто невозможно. Я руковожу инженерной командой, которая разрабатывает интеграционный слой для подключения к 32 бухгалтерским системам и системам ERP; поверх него при необходимости можно развернуть MCP-сервер. Мы регулярно видим, как агенты, прошедшие надлежащую аутентификацию, ограниченные нужными полномочиями и подробно регистрируемые в журналах на нашей стороне, вносят данные в системы, которые вообще не способны определить, что в этом участвовал агент.

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

Где заканчиваются требования спецификации MCP

Эта спецификация авторизации MCP четко обозначает собственные границы. Сервер MCP является сервером ресурсов OAuth для своих клиентов. Когда он обращается к вышестоящему API, он действует как отдельный OAuth-клиент и использует отдельный токен, выданный вышестоящей системой. Явно запрещено передавать токен клиента.

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

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

Что на самом деле предлагают вышестоящие системы

Вот как выглядят 32 бухгалтерские системы и системы ERP, к которым мы подключаемся, с точки зрения интегратора.

У трети систем вообще нет OAuth

21 из 32 систем используют OAuth. Остальные 11 полагаются на статические учетные данные: ключи API, имя пользователя и пароль либо пару токенов. Срок действия некоторых таких ключей никогда не истекает. В документации одной широко используемой системы указано, что ее токены API действуют неограниченно долго, пока существует пользователь.

Долгий срок действия, ограниченные возможности отзыва

OAuth помогает меньше, чем хотелось бы. Один поставщик выдает токены обновления со сроком действия около 20 лет. Такие учетные данные рассчитаны на то, чтобы пережить агента, который ими пользуется, платформу, на которой он создан, и, вполне возможно, человека, нажавшего кнопку «Разрешить». В другой системе даже срок действия токенов доступа не истекает.

Но когда учетные данные уже выданы, возникает вопрос: кто может их отключить? Стандарт, регламентирующий отзыв токенов OAuth (RFC 7009), действует с 2013 года. И все же примерно в четырех из десяти систем у интегратора нет технической возможности отозвать учетные данные. К этой группе относятся все системы с ключами API. Единственный доступный вариант — попросить клиента вручную отозвать доступ.

Грубые настройки полномочий, отсутствие идентификации агента

Большинство статических ключей просто наследуют все права пользователя, который их создал; лишь в немногих системах можно ограничить ключ отдельными конечными точками. Во многих системах OAuth есть области действия, но они, как правило, довольно широкие — например, «бухгалтерский учет: чтение и запись». Ни в одной из 32 систем мы не нашли способа через API зафиксировать в рамках одной транзакции и агента, и человека, от имени которого он действует. Внешние агенты отображаются либо как подключивший их пользователь, либо как обычная системная учетная запись. Примечательно, что поставщик, встроивший агентов в собственный продукт, как это сделала Microsoft в Business Central, выделил им отдельные учетные записи. Это тот же подход, который я рекомендую ниже, но пока он доступен только для собственных агентов поставщика.

Что может обеспечить интеграционный слой

Все это не повод сдаваться. Между агентом и бухгалтерской системой вы контролируете почти все:

• отдельные учетные данные для каждого агента при обращении к вашему слою
• собственные области действия, например доступ к счетам-фактурам только для чтения
• журнал аудита каждого вызова агента с указанием человека, от имени которого он действовал
• ключи идемпотентности, чтобы при повторной попытке агент не зарегистрировал один и тот же счет-фактуру дважды
• ограничение частоты запросов для каждого агента
• этапы согласования перед любой записью данных

Ничто из этого не зависит от возможностей целевой системы. Уже сегодня можно создать полноценный слой управления доступом на уровне интеграции, и если вы допускаете агентов к финансовым данным, вам следует такой слой разработать.

Где заканчиваются его возможности

Однако распространить этот уровень за пределы системы нельзя. Здесь возникают три проблемы.

Атрибуция

В бухгалтерской системе запись, внесенная агентом, отображается от имени пользователя, который авторизовал подключение, или технического пользователя. При аудите системы видно, что проводку сделал этот пользователь. Невозможно понять, человек это был или агент. Для учетной книги агент, который проводит 400 счетов-фактур в 3 часа ночи, ничем не отличается от очень добросовестного финансового менеджера. Чтобы восстановить картину, понадобятся журналы интегратора, а это уже другая цепочка доверия, не та, что у системы учета. Для расследования инцидента или аудита это ненадежная ситуация.

Большинство организаций тоже пока не продвинулись в этом вопросе. Согласно опросу Cloud Security Alliance, лишь 28% респондентов заявили, что могут надежно отслеживать действия агентов и устанавливать, какой человек или система их выполняли, во всех средах, а 44% используют или планируют использовать для своих агентов статические ключи API.

Минимальные привилегии

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

Отзыв доступа

Вы можете мгновенно отключить собственного агента. Но это не поможет, если скомпрометированы учетные данные самой целевой системы. А в четырех системах из десяти, где нет конечной точки для отзыва доступа, аварийное отключение сводится к отправке письма клиенту.

Практичное решение: отдельная учетная запись для агента

Самое полезное, что можно сделать уже сегодня, — не самая эффектная мера. Создайте для агента отдельную учетную запись в целевой системе и подключайте агента только через нее.

Этот подход работает во всех системах, где можно создавать учетные записи, и дает три преимущества, недоступных интеграционному уровню:

• Атрибуция в системе учета. Проводки будут отображаться от имени «агента по работе с кредиторской задолженностью», а не финансового менеджера, который нажал кнопку «Подключить» шесть месяцев назад.
• Возможность отозвать доступ, даже если для этого нет API. Клиент может отключить учетную запись в интерфейсе. Это работает и в системах, где нет конечной точки для отзыва доступа.
• Частичное ограничение привилегий. Если в системе вообще предусмотрены роли, учетную запись агента часто можно ограничить модулями, которые ему действительно нужны.

Издержки реальны. Во время подключения кто-то должен вручную создать учетную запись, что добавляет лишние трудности именно в самый неподходящий момент. Примерно половина систем взимает плату за каждую дополнительную учетную запись: от нескольких евро в месяц в инструментах для малого бизнеса до более чем ста евро в полноценной ERP-системе. В некоторых других системах число пользователей ограничено тарифным планом, поэтому еще одна учетная запись может вынудить всю компанию перейти на более дорогой план. Кроме того, служебная учетная запись, за которую никто не отвечает, сама становится источником риска и частью разрастания числа нечеловеческих идентификаторов, о котором Unite.AI уже писала. Как и у любой другой учетной записи, у нее должны быть ответственный владелец и дата проверки.

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

Структурное решение: делегированная идентификация

Правильное решение уже существует на бумаге: обмен токенами OAuth 2.0 (RFC 8693)различает имперсонацию и делегирование. При делегировании агент сохраняет собственную идентичность, а в токене указывается, что он действует от имени человека, с помощью утверждения «act».

В бухгалтерском учете это означало бы следующее:

• в учетной книге указано, что эту проводку внес данный агент от имени данного человека
• области доступа предоставляются для каждого делегирования, а не для каждой учетной записи
• делегирование можно отозвать отдельно, не затрагивая учетную запись человека

Насколько мне удалось выяснить, ни одна из 32 систем не поддерживает ничего подобного. Поэтому пока это лишь направление развития, а не доступная возможность. Значит, обращаться с таким запросом нужно к поставщикам бухгалтерского ПО и ERP-систем, а не к интеграторам: агенты уже вносят записи в ваши учетные книги, и ваши API должны уметь это отражать.

Что сделать, прежде чем агент получит доступ к учетной книге

Если вы подключаете агентов к бухгалтерским системам или ERP-системам, воспользуйтесь коротким списком проверок:

1. Изучите модель учетных данных каждой целевой системы. Используется OAuth или статический ключ? Как долго действуют учетные данные? Предусмотрены ли области доступа и можно ли отозвать доступ?
2. В любом случае создайте собственный уровень управления доступом. Идентификаторы для каждого агента, области доступа, идемпотентность и согласования должны быть на вашей стороне — независимо от возможностей целевой системы.
3. Везде, где это позволяет система, используйте для агента отдельную учетную запись. Будьте готовы потратить время на ее создание и оплатить лицензию — такова цена атрибуции.
4. Ведите собственный журнал аудита, защищенный от незаметного изменения. Для многих систем это будет единственная запись, подтверждающая участие агента.
5. Зафиксируйте остаточный риск. Если в системе не предусмотрены ограничения прав доступа и механизм их отзыва, сообщите об этом клиенту и внесите эту информацию в собственный реестр рисков.

Граница — вот что важно

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

Хорошая новость: этот пробел четко определен. Стандарты существуют. Не хватает лишь поддержки этих стандартов в системах, в которых ведется учет.