ksxz
MCPSecurity

在生产环境中保护 MCP：超越网关的纵深防御

Nik Kale··原文链接
收录于 2026/10/12 09:51:43

2025 年底，作者团队将 MCP（Model Context Protocol）作为生产级多智能体平台的集成层。核心问题：在大规模自动化执行之前，需要哪些架构控制才能信任它？答案是需要四个层面的纵深防御，每项在对应的可信点上强制执行，而非仅依赖网关。

背景：漏洞井喷与规范滞后

2026 年前六十天，针对 MCP 部署的 CVE 报告超过 30 个。Adversa AI 三月扫描 500+ MCP 服务器：38% 关键端点缺少认证，43% 存在命令执行漏洞。微软修复 Azure MCP Server SSRF 漏洞（CVE-2026-26118，CVSS 8.8），可导致托管身份令牌泄露。企业级 MCP 使用速度远快于安全规范成熟速度。

MCP 安全是控制平面问题

网关是正确的直觉——集中认证、授权、审计与策略评估。但网关只是一个强制执行点，不是完整的控制平面。它无法确保工具处理器安全执行参数，无法隔离管理平面组件，无法阻止过宽凭据的出站调用，也无法检测工具定义漂移。

对每种故障模式都问：最早的可信强制执行点在哪里？

四个控制层

图1：四个 MCP 控制层、代表性攻击与主要控制点（详见正文描述）

图 1. 四个 MCP 控制层、代表性攻击与主要控制点，以及网关仅部分覆盖的区域。来源：作者绘制。

表1：四层控制矩阵（详见正文中的控制层描述）

表 1. 四层控制矩阵

四层概述：

  • 第 1 层 · 执行：调用工具时运行的代码，工具处理器必须将参数视为数据而非指令。
  • 第 2 层 · 管理基础设施：检查器、harness、注册界面和管理控制台。
  • 第 3 层 · 出站信任边界：服务器运行时自行可达的目标。
  • 第 4 层 · 语义完整性：工具定义随时间推移含义是否保持一致。

每层有不同的最早可信任强制执行点，网关只参与其中两层且仅部分参与。

第 1 层：安全的工具执行

30 个 CVE 中有 13 个呈现相同模式：未验证的用户输入到达 shell 或动态解释器。CVE-2026-2130、2178、2131 均通过 exec() 执行工具参数；CVE-2026-1977 使用 eval()；CVE-2026-27203 通过换行符操纵环境变量。

核心原则：工具处理器不是便捷的包装器，而是受控的输入边界。使用数组参数传递代替字符串插值：

// VULNERABLE
exec(`docker run maigret ${username}`);

// FIXED: array-based argument passing
execFile('docker', ['run', 'maigret', username]);

CI Semgrep 规则可在构建时阻止不安全执行模式（覆盖 JS/TS 和 Python），捕获 exec()、eval()、shell=True 等常见汇流点。Huang 等人的 114 个恶意 MCP 服务器数据集表明多组件攻击链更有效，支持分层防御——不应期望单一控制捕获所有问题。

第 2 层：保护管理平面

测试 harness 监听未认证内部网络——关闭只需 20 分钟，但默认开放。30 个 CVE 中有 6 个针对开发与运行基础设施。CVE-2026-23744（MCPJam Inspector）默认监听 0.0.0.0 可安装任意服务器；CVE-2026-23523（Dive MCP Host）通过深链接安装恶意配置。

管理平面至关重要：开发环境通常比生产环境拥有更多访问权限（源代码、密钥、构建系统）。对管理平面的期望应与 CI/CD 控制面一致：

  • 禁止匿名访问
  • 默认不对外暴露内部网络
  • 最小化文件系统可达范围
  • 尽可能使用短期凭据
  • 管理端点必须认证并记录日志

第 3 层：出站信任、出站限制与令牌作用域

Azure MCP Server SSRF（CVE-2026-26118）说明仅靠入站认证不够——攻击者替换 Azure 资源标识符为恶意 URL，服务器用托管身份令牌发起出站调用。需并行采用三项控制：

  1. 对每个入站端点强制认证
  2. 受控出站访问（egress allow list）
  3. 下游凭据权限最小化，令牌影响范围与工具影响范围匹配
# NetworkPolicy 限制 MCP 服务器出站流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: mcp-server-egress
spec:
  podSelector:
    matchLabels:
      app: mcp-server
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8
      ports:
        - port: 443
    - to:
        - namespaceSelector: {}
      ports:
        - port: 53
          protocol: UDP

注意：集群 CNI 必须真正执行 NetworkPolicy（Calico、Cilium 可做到），建议与命名空间默认拒绝策略配对。自动化的文件搜索工具不应持有可控制公司云账户的访问令牌。

第 4 层：语义完整性与 Manifest 固定

最具架构意义的攻击是语义层面的：请求格式正确、模式合法、通过认证，但工具含义在授予信任后发生漂移。Solo.io 提出 "rug-pull" 攻击——服务器注册后改变工具定义。Maloyan 与 Namiot（2026）将其正式化为"缺乏能力认证"。

Manifest 固定控制类似于 Web 子资源完整性（SRI）：

  1. 注册时网关对工具 Manifest（名称、描述、参数模式）规范化并哈希
  2. 重新连接时比较哈希：相同则允许更新
  3. 不同则交由差异分类器，区分外观性修改与实质性模式变化
function pin(serverId: string, tools: ToolManifest[]): PinResult {
  const canonical = canonicalize(tools);
  const hash = createHash('sha256').update(canonical).digest('hex');
  const existing = registry.get(serverId);
  if (!existing) {
    registry.set(serverId, { hash, tools, signedAt: Date.now() });
    return { outcome: 'registered', hash };
  }
  if (existing.hash === hash) {
    return { outcome: 'unchanged', hash };
  }
  const diff = diffSchemas(existing.tools, tools);
  if (diff.cosmeticOnly) {
    registry.set(serverId, { hash, tools, signedAt: Date.now() });
    return { outcome: 'auto-approved-cosmetic', hash };
  }
  operatorQueue.push({ serverId, diff });
  return { outcome: 'pending-review', hash };
}

差异分类器使控制运维可持续——评审队列只包含真正需要人工决策的条目。建议配合行为监控：监控服务器实际访问端点、数据移动量与延迟模式，当被批准的文件搜索工具开始向未知域发起外部 HTTP 请求时触发告警。

网关的定位

网关仍必要：客户端认证、策略授权、审计轨迹、速率限制、注册工作流。但安全执行、管理平面隔离、出站限制、语义漂移检测发生在不同层。正确做法是将网关视为多层安全方案的一个组件。优步和 Pinterest 的生产实践均体现了这一分层方法。

四周推广计划

周次主题关键动作
第 1 周稳定明显边界端点强制认证、管理组件迁移隔离网络、限制文件系统访问
第 2 周执行路径安全CI 规则标记 shell 插值/eval/shell=True、热点路径转数组参数
第 3 周信任限制出站允许列表、工具特定作用域令牌替换宽泛凭据
第 4 周语义控制Manifest 固定差异评审、收集 2-3 周行为基线、偏差告警

取舍权衡

  • 容器化/沙箱执行：每次工具调用增加 50-200ms 延迟
  • 出站允许列表：可能破坏需要新端点的服务器（大多数连接 3-5 个内部服务 + 1-2 个外部 API）
  • Manifest 固定：为演进中的服务器带来冲突，差异评审可缓解但无法消除
  • 行为监控：基线稳定前有成本与误报（通常 2-3 周后趋于稳定）

这些成本远小于凭据泄露或工具滥用造成的损失。最常见的失误不是过度保护，而是低估了信任边界的数量。

结论

生产 MCP 部署需要四层控制：安全工具执行（第 1 层）、隔离管理平面（第 2 层）、受限出站信任（第 3 层）、Manifest 固定的语义完整性（第 4 层）。每层有最早可信执行点，通常不是网关。

去保护第一个授予信任的边界，而不只是保护流量通过的边界。

规范会随后补上，但生产不能等待。本文的控制方式与当前 MCP 规范和基础设施兼容，可立即实施。

评分：
暂无（0 人评分）
返回首页返回索引