Firewall: MCP Servers

Model Context Protocol (MCP) позволяет агентам вызывать инструменты, размещённые на внешних серверах. Это в равной мере мощно и опасно: каждый MCP-сервер, к которому подключается агент, — это свежий набор инструментов, учётных данных и сетевого охвата, который никто не проверял. MCP-шлюз Firewall ставит единую аудируемую узловую точку перед всеми ними. Вы регистрируете каждый MCP-сервер один раз; шлюз выставляет их инструменты вашим агентам под одним подключением и прогоняет каждый tools/call через движок firewall, прежде чем он достигнет реального сервера.

1. Что даёт управление MCP

Один шлюз, каждый сервер. Ваш агент подключается к одному эндпоинту. Шлюз агрегирует инструменты каждого достижимого зарегистрированного сервера в пространстве имён <server>.<tool>, так что github.create_issue и shell.exec показываются бок о бок под одним MCP-подключением.
Политика на каждом вызове. Каждый tools/call сначала вычисляется вашей политикой. Заблокированный вызов возвращается модели как ошибка инструмента (firewall deny: …), а не сбой транспорта, так что агент может среагировать вместо падения. sanitize переписывает аргументы перед пересылкой; pending_approval удерживает вызов.
Защита от SSRF. Удалённые эндпоинты валидируются по SSRF-политике шлюза — интранет-диапазоны и адреса облачных метаданных блокируются, а разрешённый IP набора перепроверяется, чтобы победить DNS rebinding, на каждом хопе, включая редиректы.
Зашифрованные учётные данные. Секреты аутентификации сервера шифруются в покое и маскируются при чтении. Шлюз внедряет их во время диспетча; они никогда не достигают модели или клиента.

2. Два вида сервера

Вид	`endpoint`	Поведение
BYO (bring-your-own)	URL streamable-HTTP	Шлюз проксирует `tools/call` на ваш удалённый MCP-сервер.
Bundled	пусто	Внутрипроцессный MCP-сервер OrcaRouter. Зарегистрирован, чтобы быть видимым и управляемым; отдельно не проверяется зондом.

3. Регистрация сервера

Запись сервера несёт:

Поле	Примечания
`name`	Бизнес-ключ, уникальный в рамках рабочего пространства, ≤ 128 символов. Без `.` — это разделитель пространства имён `<server>.<tool>`.
`endpoint`	URL MCP-сервера (≤ 512 символов). Пусто для встроенного сервера.
`auth_mode`	`none` (по умолчанию), `bearer`, `oauth` или `basic`.
`auth_json`	Специфичные для режима учётные данные (см. ниже). Требуются всякий раз, когда `auth_mode` не `none`.
`enabled`	По умолчанию `true`. Отключённый сервер полностью исключается из шлюза.
`status`	Достижимость — `ok` (по умолчанию), `degraded` или `down`. Устанавливается зондированием.

Формы учётных данных по режимам:

// bearer
{ "token": "ghp_…" }
// oauth
{ "client_id": "…", "client_secret": "…", "token_url": "…" }
// basic
{ "username": "…", "password": "…" }
// none
""

Запрос на регистрацию выглядит так:

curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'

Дублирующееся имя в том же рабочем пространстве возвращает HTTP 409 (то же имя в другом рабочем пространстве допустимо).

Секреты никогда не хранятся в открытом виде. auth_json шифруется в покое ключом секретов рабочего пространства. Если этот ключ не настроен, запись отклоняется, а не сохраняет учётные данные нешифрованными. При чтении секреты и эндпоинт маскируются; верните маску обратно при обновлении, чтобы сохранить хранимое значение. Переключение между двумя режимами аутентификации с учётными данными требует свежего auth_json (шифротекст привязан по форме к своему режиму).

4. Probe — обнаружить его инструменты

Прежде чем писать правила против инструментов сервера, вам нужно знать их имена. Зондируйте (Probe) сервер:

curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer sk-orca-..."

Шлюз прогоняет MCP initialize + tools/list против эндпоинта (используя расшифрованные учётные данные, с ограничением в 10с), записывает достижимость status и временную метку и возвращает рекламируемые инструменты с их входными схемами:

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": { } }
  ]
}

Теперь вы можете писать правила вроде tool_name_glob: github.*, точно зная, что принимает github.create_issue. Встроенный сервер (с пустым endpoint) не зондируется и возвращает 400.

5. Жизненный цикл и применение

Enabled vs. disabled. Отключённый сервер выбрасывается из рантайм-реестра — его инструменты исчезают из шлюза, а его учётные данные никогда не расшифровываются. Это выключатель.
Достижимость. status (ok / degraded / down) отражает последний зонд; недостижимый сервер пропускается, когда шлюз строит свой набор инструментов.
Вердикт на каждый вызов. При диспетче движок возвращает вердикт для конкретного вызова <server>.<tool> с его аргументами:
- allow / audit → переслано (audit логирует, всё равно разрешает).
- sanitize → переслано с переписанными аргументами.
- deny / pending_approval / что-либо неизвестное → заблокировано как ошибка инструмента. (Через единый шлюз удержанный вызов всплывает как постоянная ошибка, а не протягивает id подтверждения — используйте хук evaluate, когда вам нужно рукопожатие подтверждения.)
Удаление — это soft-delete; слот имени освобождается немедленно, так что вы можете перерегистрировать под тем же именем.

Каждое изменение немедленно инвалидирует per-workspace кэш инструментов шлюза, так что вновь зарегистрированный, отключённый или переснованный сервер вступает в силу на следующем подключении, а не после TTL кэша.

6. Подключение клиента

Направьте любой MCP-клиент на эндпоинт шлюза с токеном области firewall-gateway:

https://api.orcarouter.ai/api/v1/firewall/mcp

Шлюз говорит на streamable HTTP (POST-сообщения, GET для SSE-потока, DELETE для завершения сессии) и идентифицирует себя как orcarouter-firewall-gateway. Он рекламирует инструменты каждого включённого, достижимого сервера под пространством имён <server>.<tool>, переэкспонируя входную схему каждого инструмента дословно. Токен без области firewall-gateway получает 403 — выпустите выделенный токен шлюза для этого.

API-справочник

Консоль (в рамках рабочего пространства, RBAC)

Метод и путь	Роль	Назначение
`GET /api/workspace/firewall/mcp_servers`	Member	Список серверов (секреты замаскированы, эндпоинт отредактирован).
`GET /api/workspace/firewall/mcp_servers/:id`	Member	Один сервер, замаскирован.
`POST /api/workspace/firewall/mcp_servers`	Developer+	Зарегистрировать сервер (409 при дублирующемся имени).
`PUT /api/workspace/firewall/mcp_servers`	Developer+	Обновить сервер (id в теле).
`DELETE /api/workspace/firewall/mcp_servers/:id`	Developer+	Soft-delete; освобождает имя.
`POST /api/workspace/firewall/mcp_servers/:id/probe`	Developer+	Зондировать достижимость + обнаружить инструменты.

Шлюз (токен области firewall-gateway)

Метод и путь	Назначение
`ANY /api/v1/firewall/mcp`	Единый эндпоинт диспетча MCP-шлюза.
`GET /api/v1/firewall/mcp_servers`	Рантайм-реестр (расшифрованная аутентификация, только включённые серверы) для SDK-прокси.
`POST /api/v1/firewall/evaluate`	Вычислить один `tools/call` перед тем, как диспетчить его самостоятельно.

FAQ

Зачем вообще маршрутизировать MCP через OrcaRouter?

Чтобы было одно место, которое видит каждый вызов инструмента. Без шлюза каждый агент подключается к каждому MCP-серверу напрямую — нет общей политики, нет следа аудита, нет защиты от SSRF, а учётные данные разбросаны по конфигам агентов. Шлюз централизует всё это: одно подключение, одна политика, один аудируемый лог, зашифрованные секреты, внедряемые при диспетче.

Что происходит, когда заблокированный MCP-вызов возвращается?

Модель получает его как ошибку инструмента (firewall deny: <reason>), в той же форме, какую она получила бы от любого сбойного инструмента. Это позволяет агенту адаптироваться — попробовать другой подход, спросить пользователя или остановиться — вместо того чтобы трактовать это как сбой транспорта.

Могу ли я управлять одним и тем же инструментом по-разному на разных серверах?

Да — именно для этого нужно пространство имён <server>.<tool>. Правило с tool_name_glob: trusted.* может allow, пока community.* аудируется (audit) или pending_approval. Скомбинируйте его с глобом имени навыка для ещё более тонкого охвата.

Защищает ли шлюз от SSRF?

Да. URL-эндпоинтов и их разрешённые IP набора валидируются по SSRF-политике при регистрации и на каждом хопе диспетча — интранет-диапазоны и адрес облачных метаданных отвергаются, а разрешённый IP перепроверяется, чтобы победить DNS rebinding. Сочетайте это с egress-правилом, чтобы управлять тем, куда инструменты могут обращаться.

Смотрите также

Хотите глубже разобраться в безопасности агентов? Руководства «Защитите агентов — Zero Trust» встраивают эту функцию в рабочий процесс нулевого доверия.

Защитите MCP-серверы (Zero Trust)

Подключайте, аутентифицируйте и управляйте MCP-серверами в позиции нулевого доверия.

Чек-лист доверия MCP

Что проверить, прежде чем доверять стороннему MCP-серверу.

​1. Что даёт управление MCP

​2. Два вида сервера

​3. Регистрация сервера

​4. Probe — обнаружить его инструменты

​5. Жизненный цикл и применение

​6. Подключение клиента

​API-справочник

​Консоль (в рамках рабочего пространства, RBAC)

​Шлюз (токен области firewall-gateway)

​FAQ

​Смотрите также