MCP生产治理与安全加固#

一、认证与授权

认证方案选型：

MCP 规范对 HTTP 传输授权的硬性要求（2026-07-28 版，以官方文档为准）：

• MCP Server 是 OAuth 2.1 资源服务器，必须提供 Protected Resource Metadata（RFC 9728），未带令牌时返回 401 + WWW-Authenticate 指向元数据地址
• Client 申请令牌必须带 PKCE 和 resource 参数（RFC 8707），令牌只对这一个 Server 有效
• Server 必须校验令牌的受众是自己；禁止把收到的令牌透传给下游 API（防混淆代理攻击）
• 令牌只能放在 Authorization: Bearer 头里，不能放 URL 查询串
• 权限不足返回 403 + insufficient_scope，Client 走增量授权（step-up）补 scope
• 客户端注册优先用 Client ID Metadata Documents，动态客户端注册（DCR）已标记废弃
• stdio 传输不走这套，凭证从环境变量取

工具级权限分级：

权限模型：RBAC + 工具粒度

角色定义：
  viewer:  只能调用查询类工具（search, read, list）
  editor:  可以调用修改类工具（create, update）
  admin:   可以调用危险工具（delete, execute, admin-*)

权限检查点：
  Client → [认证] → [角色解析] → [工具权限检查] → 执行工具
                                       ↓
                              tools_allowed: ["search_*", "read_*"]
                              tools_denied:  ["delete_*", "execute_*"]

最小权限原则：

• 每个 MCP Client 只授予完成任务所需的最小工具集，scope 按需增量申请
• 高危工具（写数据库、发邮件、执行代码）需要额外审批；工具注解（readOnlyHint、destructiveHint 等）可辅助分级，但规范要求把来自不可信 Server 的注解视为不可信，权限判断以服务端配置为准
• 工具权限随令牌有效期绑定，令牌过期或吊销即回收

二、会话与连接管理

协议层现状： 2026-07-28 版 MCP 改为无状态：去掉了 initialize 握手、Mcp-Session-Id 会话头、ping，以及 Streamable HTTP 的 SSE 断点续传（Last-Event-ID）。每个请求在 _meta 里自带协议版本和客户端能力；Client 可先调 server/discover 查 Server 支持的版本和能力。所以下面的”会话”指应用层会话（认证令牌 + 服务端业务状态），不是协议握手。

请求生命周期（2026-07-28 版）：

Client → [可选] server/discover（查版本/能力）
  → 带 Bearer 令牌发请求（_meta 带协议版本+能力）→ 认证
  → 工具发现(tools/list) → 工具调用(tools/call) → ...
  → 令牌过期 / 空闲超时 → 重新认证；服务端清理过期的业务状态

旧版本（2025-11-25 及以前）是 initialize 握手协商版本和能力后建立会话，Streamable HTTP 用 Mcp-Session-Id 标识会话。

关键参数（应用层，经验值，按业务调整）：

断线语义（2026-07-28 版）：

• 响应流断开：进行中的请求丢失，Client 必须用新的请求 ID 重发，所以有副作用的工具要幂等（带幂等键）
• 令牌过期：重新认证后重发请求
• 服务端重启：协议层无状态，任意实例都能接请求；业务状态靠外部存储（数据库/Redis）或 checkpoint 恢复
• 长耗时操作：用 Tasks 扩展（返回任务句柄，Client 用 tasks/get 轮询）

有状态 vs 无状态：

• 无状态工具调用（查询类）：每次请求独立认证，天然适合水平扩展
• 有状态工具调用（多步操作，如打开文件→编辑→保存）：新版协议没有会话，由 Server 签发显式句柄（如 file_handle）作为普通工具参数传递，状态存在服务端外部存储

三、审计日志

审计字段设计：

{
  "timestamp": "2026-05-26T10:30:00Z",
  "trace_id": "abc-123",
  "client_id": "client-xyz",
  "tenant_id": "tenant-001",
  "user_id": "user-456",
  "session_id": "sess-789",
  "action": "tools/call",
  "tool_name": "database_query",
  "tool_params": {"query": "SELECT ...", "database": "prod"},  // 脱敏处理
  "result_status": "success",
  "result_summary": "returned 42 rows",  // 不记录完整结果
  "latency_ms": 156,
  "token_cost": 0,
  "risk_level": "medium"  // low/medium/high/critical
}

审计策略：

• 所有工具调用必须记录，无例外
• 高危工具（写入/删除/执行）的参数全量记录
• 查询类工具只记录摘要，不记录完整返回值（防止日志膨胀）
• 参数中的敏感信息（密码/Token）脱敏处理
• 审计日志独立存储，与业务日志分离
• 保留期限：至少90天，合规要求可能更长

四、限流与防滥用

多层限流设计：

L1 网关层：全局限流（保护MCP Server整体）
  └─ 总QPS上限，超过直接拒绝

L2 客户端层：per-client 限流（防单客户端滥用）
  └─ 令牌桶算法，不同付费等级不同配额

L3 工具层：per-tool 限流（保护下游依赖）
  └─ 数据库查询工具: 100次/min
  └─ 代码执行工具:   10次/min
  └─ 邮件发送工具:   5次/min

L4 载荷层：请求体大小限制
  └─ 单次请求参数: < 1MB
  └─ 工具返回结果: < 10MB
  └─ 单次执行时间: < 60s

防滥用措施：

• 异常检测：单客户端短时间大量调用高危工具 → 自动临时封禁
• 参数校验：SQL注入检测、路径遍历检测、命令注入检测
• 执行沙箱：代码执行类工具在隔离容器中运行
• 结果过滤：敏感数据检测（PII、密钥）→ 自动脱敏或拦截

五、Schema 演进与版本治理

工具 Schema 版本化：

MCP 协议本身只对”协议版本”做协商（日期版本号），工具定义里没有标准的 version 字段，工具级版本号是应用层约定，可放在工具名后缀或 _meta 里。下面的 version 即为示意：

{
  "name": "database_query",
  "version": "2.1.0",
  "description": "Execute SQL query",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {"type": "string"},
      "database": {"type": "string"},
      "timeout_ms": {"type": "integer", "default": 5000}  // v2.1新增
    },
    "required": ["query", "database"]
  }
}

向后兼容原则：

• 新增可选参数：兼容（旧客户端不传，用默认值）
• 新增工具：兼容（旧客户端不知道新工具，不调用就行）
• 删除参数/工具：不兼容 → 需要废弃期（先标记deprecated，下个大版本移除）
• 修改参数类型/语义：不兼容 → 创建新版本工具

废弃流程：

v2.0: tool_A 正常使用
v2.1: tool_A 标记 deprecated，新增 tool_A_v2
v3.0: 移除 tool_A，tool_A_v2 改名为 tool_A

版本协商：

• 协议版本（2026-07-28 版）：Client 可先调 server/discover 获取 Server 支持的协议版本，之后每个请求在 _meta 里带所用版本；版本不支持时 Server 返回 UnsupportedProtocolVersionError
• 工具版本（应用层）：新旧工具并存一段时间，tools/list 里给废弃工具的描述加 deprecated 标记和迁移指引
• 不兼容时返回明确错误和升级指引

六、外部暴露安全加固

MCP从Demo到生产需要补齐五层安全加固。第一层认证授权：远程MCP按规范走OAuth 2.1，令牌必须绑定到本Server、不能透传给下游，内部服务可以用API Key加HMAC签名，关键是工具级权限控制，高危工具如写数据库、发邮件需要额外授权。第二层会话与连接管理：最新的2026-07-28版协议已经无状态化，去掉了握手和会话头，所以会话管理落在应用层——短令牌加刷新，业务状态用服务端签发的句柄传递，断线后请求要重发，有副作用的工具必须幂等，长耗时操作走Tasks扩展异步轮询。第三层审计日志：每次工具调用必须记录who/what/when/result四要素，高危操作全量记录参数，敏感信息脱敏。第四层限流防滥用：分网关级全局限流、客户端级令牌桶、工具级独立限流三层，再加载荷大小和执行时间限制。第五层Schema演进：工具接口版本化，遵循向后兼容原则，删除和修改走deprecated过渡期。整体思路是把传统API网关的治理能力搬到MCP协议上，同时针对AI场景加了工具权限分级和参数注入检测。

追问方向：

• “MCP 和 REST API 安全的核心区别？”→ MCP 工具由 LLM 自主选择调用，存在间接 Prompt Injection 风险（用户输入诱导 LLM 调用高危工具）；需要额外的工具权限管控层，不能像 REST API 一样只靠认证鉴权
• “工具执行超时怎么处理？”→ 设置执行超时阈值（如 30s），超时后返回 partial 结果或错误码；长耗时工具走异步模式（MCP 的 Tasks 扩展：返回任务句柄→tasks/get 轮询），避免阻塞 Agent 主循环
• “如何防止 LLM 被 Prompt Injection 诱导调用危险工具？”→ 工具权限白名单（只开放必要工具）+ 高危工具（如删除/支付）强制人工审批 + 输出审查（检测 LLM 响应中是否包含可疑指令）
• “多租户场景下 MCP Server 怎么部署？”→ 共享 Server + 租户路由适合轻量级隔离（成本低），独立 Server per 租户适合强隔离要求（如金融/医疗）；选择取决于安全合规要求和成本预算
• “Schema 变更如何通知客户端？”→ 协议内：Client 通过 subscriptions/listen 订阅 toolsListChanged，列表结果的 ttlMs 控制缓存多久后重新拉取（2026-07-28 版）；应用层：tools/list 中对废弃工具带 deprecated 标记和迁移指引 + changelog 通知
• “新版 MCP 去掉会话后，多步有状态操作怎么做？”→ Server 签发显式句柄作为工具参数传递，状态存外部存储；断线时请求丢失需重发，所以写操作要带幂等键

易错点：

• ❌ “MCP是内部协议不需要认证”——一旦暴露给外部客户端，安全要求等同于公开API
• ❌ “MCP Server 拿到用户令牌直接转发给下游 API”——规范禁止令牌透传，下游要用 Server 自己的凭证
• ❌ “靠心跳和会话 ID 维持 MCP 连接”——2026-07-28 版已去掉 ping 和 Mcp-Session-Id，协议层无会话
• ❌ “限流只看QPS”——AI场景还要限Token消耗和执行时长
• ❌ “审计日志记录完整返回值”——返回值可能包含大量数据，应只记录摘要
• ❌ 忽略工具参数注入——LLM生成的SQL/命令可能被间接注入操控
• ✅ 核心思路：把MCP当成一个”由AI驱动的API网关”来治理