Безопасность шлюза MCP: докажите, что каждый вызов инструмента пересекает ворота

Безопасность шлюза MCP не устанавливается путем включения прокси сервера в диаграмму архитектуры. Защищенное значение по умолчанию более строгое: докажите, что каждый вызов защищенного производственного инструмента пересекал предполагаемый шлюз, использовал ожидаемую версию политики, имел подтвержденную идентификацию и область с наименьшими привилегиями, создавал квитанцию ​​об аудите и заканчивался проверенным эффектом или явным состоянием ожидания . Это различие имеет значение, поскольку «ворота» описывают размещение, а не результат. Текущие результаты поиска в США сочетают в себе продукты шлюзов, сравнения, объяснения архитектуры и заявления о безопасности. Их общее обещание — центральная точка управления между агентами и серверами MCP. Операционный вопрос заключается в том, действительно ли эта точка владела конкретным вызовом. Этот Спецификация авторизации MCPопределяет авторизацию для HTTP транспорта, метаданных защищенных ресурсов, обнаружения и выбора области. Протоколлучшие практики безопасноститребуют от разработчиков учитывать риски, связанные с замешательством депутатов, проверку аудитории токена, опасности прохождения токена, согласие и возможность аудита. Ни один из документов не превращает простое присутствие посредника в доказательство того, что каждый маршрут контролируется. Определите контракт доказательства перед маршрутизацией трафика Начните с манифеста маршрута, достаточно маленького, чтобы его можно было отправить вместе с конфигурацией шлюза: Манифест создает пять проверяемых утверждений: 1. запрос прошел через именованный шлюз, а не через прямой URL адрес сервера; 2. шлюз подтвердил несекретную рабочую нагрузку или личность пользователя; 3. решение было принято в результате ожидаемого нового пересмотра политики; 4. предоставленная область охватывала выбранный инструмент без молчаливого расширения доступа; 5. шлюз выдал подтверждение аудита, которое можно присоединить к нисходящему результату. Утверждение маршрута не является теоретическим. Текущее состояние CloudflareДокументация по порталам сервера MCPописывает дополнительный путь шлюза для вызовов инструментов, а фоновая синхронизация подключается напрямую к вышестоящим серверам. Он также предупреждает, что заблокированный пользователь все равно может использовать прямой URL адрес вышестоящего сервера, если на этом сервере не применяется аутентификация. Это законное поведение, специфичное для продукта, а не универсальные правила MCP, но они демонстрируют, почему инвентаризация должна включать все пути, а не предполагать, что портал или шлюз исключили боковые двери. Запишите один конверт без содержимого на каждое решение. Ему не нужны подсказки, аргументы инструмента, тела результатов, токены доступа или секреты: Непрозрачных идентификаторов достаточно для проверки владения маршрутом, обеспечения соблюдения идентификации, актуальности политики, охвата области, состояния утверждения и непрерывности получения. Храните секретные ценности в их источнике. Если инцидент требует проверки контента, рассматривайте это как отдельный, явно разрешенный рабочий процесс с собственной границей хранения. Авторизация и применение политики взаимосвязаны, но не взаимозаменяемы. В спецификации MCP говорится, что авторизация не является обязательной для реализации; если поддерживается HTTP авторизация, защищенный сервер действует как сервер ресурсов OAuth. Таким образом, шлюз не может предоставить доказательство, отметив существование токена носителя. Он должен проверить предполагаемый ресурс и его идентичность, оценить политику соответствующего инструмента и сохранить достаточное количество несекретных доказательств для объяснения решения. Руководство по безопасности MCP прямо определяет передачу токенов как антишаблон, поскольку она может обойти средства контроля и нанести ущерб подотчетности. Воспроизведите восемь состояний, которые «разрешено» скрывает Сопутствующий фикстур содержит восемь синтетических запросов. Его классификатор применяет вентили в рабочем порядке: Запустите его локально: Каждый вердикт требует своего ограниченного ответа: Вердикт Что говорят доказательства Следующее действие GATEWAY BYPASS Защищенный вызов использовал другой маршрут или идентификатор шлюза. Инвентаризация клиента и вышестоящих конечных точек; закрыть или отдельно управлять прямым путем IDENTITY NOT ENFORCED Маршрут был центральным, но звонивший не был подтвержден Отклоняйте анонимные производственные вызовы и фиксируйте рабочую нагрузку или идентификацию пользователя на границе. POLICY DRIFT В решении использовалась старая редакция или устаревшие доказательства. Согласуйте работающий шлюз с утвержденным артефактом политики, прежде чем повторить попытку. AUTHORIZATION GAP Инструмент или его требуемая область действия не соответствовали решению. Отклоните вызов, сократите объем и добавьте случай регрессии на уровне инструмента. AUDIT GAP Возможно, вызов был разрешен, но квитанции, к которой можно присоединиться, не существует. Исправьте путь регистрации/экспорта; оставить вердикт неизвестным, а не зеленым EFFECT UNCERTAIN Транспортировка или комплектация инструмента не подтвердили место назначения Прежде чем повторить попытку, прочтите пункт назначения, особенно после таймаута. WAITING Защищенное действие имеет именованную зависимость утверждения. Уведомить владельца и сохранить сроки; не помечайте агента как застрявшего HEALTHY Маршрут, идентичность, политика, объем, аудит, утверждение и эффект согласуются. Сохраняйте квитанции через окно рассмотрения инцидентов Приоритет не позволяет удобному ожиданию утверждения скрыть обходную или устаревшую политику. WAITING доступен только после прохождения шлюзов маршрута, идентификации, политики, авторизации и аудита. Аналогично, успешный нисходящий эффект не оправдывает вызов, который обошел путь управления. Эксперимент намеренно лишен содержания. Он проверяет нормализованный контракт, а не работающий шлюзовой продукт. Сопоставьте поля вашего шлюза с прибором, а не копируйте имена полей, как если бы MCP их стандартизировал. Протокол определяет сообщения и поведение авторизации; идентификаторы редакции политики шлюза, формы квитанций аудита и верификаторы назначения остаются вариантами реализации. Отдельное разрешение от результирующего эффекта Решение о разрешении доказывает только то, что политика разрешила попытку. Это не доказывает, что инструмент запускался один раз, изменил предполагаемое место назначения или произвел запрошенный результат. Для мутации присоедините квитанцию ​​шлюза к квитанции назначения: Это особенно важно после тайм аута. Повторная попытка, поскольку шлюз не получил ответа, может дублировать эффект, уже зафиксированный вышестоящей системой. EFFECT UNCERTAIN дает оператору указание сначала согласовать пункт назначения. Шлюз может ограничить скорость или разрешить повторную попытку, но пункт назначения обычно является более надежным источником информации о наличии исходного эффекта. Для инструментов только для чтения результатом может быть проверка схемы, утверждение актуальности или детерминированное сравнение с обязательными полями задачи. Для записи отдайте предпочтение обратному чтению API, версии неизменяемого объекта, идентификатору сообщения поставщика, хеш фиксации плюс проверки или другой квитанции, принадлежащей получателю. Результат успеха JSON RPC инструмента слабее, если обещанный результат находится где то еще. Практическое внедрение может оставаться узким: 1. Выберите один производственный сервер MCP и один высокоэффективный инструмент. 2. Перечислите каждую конечную точку клиента и прямой восходящий URL адрес, который может достичь ее. 3. Закрепите идентификатор шлюза и версию политики в свидетельстве развертывания. 4. Отправьте один разрешенный зонд и один запрещенный зонд с непрозрачными идентификаторами запроса. 5. Проверьте личность вызывающего абонента, необходимый объем, решение об инструменте, актуальность и квитанцию ​​об аудите для обоих. 6. Попробуйте задокументированный прямой маршрут и докажите, что он заблокирован или явно регулируется. 7. Выполните вызов, требующий утверждения, и сохраните его как WAITING пока не примет решение названный владелец. 8. Смоделируйте тайм аут после эффекта восходящего потока, а затем докажите, что Runbook читает пункт назначения, прежде чем повторить попытку. 9. Повторите проверки после изменений шлюза, поставщика удостоверений, политики, клиента или MCP сервера. Есть пределы. Это приспособление не тестирует анализатор конкретного поставщика, механизм DLP, средства защиты от быстрого внедрения или сканер уязвимостей. Это не доказывает, что центральный шлюз является подходящей архитектурой для каждого локального сервера STDIO. Локальному процессу могут потребоваться элементы управления на уровне хоста, а не сетевой шлюз. Это также не делает Sidewisp обязательной моделью или шлюзом инструментов. Предполагаемая роль Sidewisp является смежной: объединить данные о достижимости, прогрессе, инструментах, результатах, времени и бюджете с точки зрения здоровья агентов и сохранить человеческий авторитет в вопросах восстановления. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Реальная версия представляет собой веб сайт с ранним доступом и интерактивную демонстрацию; производственный адаптер шлюза MCP, механизм оперативного мониторинга и средство автоматического восстановления не поставляются. Используйте квитанцию ​​о принудительном исполнении с текущими системами шлюза и назначения, а не предполагайте, что Sidewisp в настоящее время отслеживает или исправляет их. Решение конкретное: провести инвентаризацию маршрутов, закрепить шлюз и политику, проверить личность и область с наименьшими привилегиями, потребовать присоединяемую квитанцию ​​аудита, сохранить законное ожидание и проверить пункт назначения, прежде чем объявить об успехе. Безопасность шлюза MCP становится оперативным доказательством только тогда, когда путь управления и результат совпадают.