MCP生产治理与安全加固#

一、认证与授权

认证方案选型：

工具级权限分级：

权限模型：RBAC + 工具粒度

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

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

最小权限原则：

• 每个 MCP Client 只授予完成任务所需的最小工具集
• 高危工具（写数据库、发邮件、执行代码）需要额外审批
• 工具权限按会话粒度绑定，会话结束权限回收

二、会话管理

会话生命周期：

Client连接 → 握手(版本协商+能力声明) → 认证 → 会话建立
  → 工具发现(listTools) → 工具调用(callTool) → ...
  → 空闲超时/主动断开/异常断开 → 会话清理

关键参数：

重连语义：

• 短暂断开（reconnect_window 内）：恢复会话状态，继续之前的工具调用
• 超时断开：需要重新认证，之前的会话状态丢弃
• 服务端重启：通知客户端重建会话，checkpoint 恢复进行中的任务

有状态 vs 无状态：

• 无状态工具调用（查询类）：不需要会话保持，每次请求独立认证
• 有状态工具调用（多步操作）：需要会话保持上下文（如：打开文件→编辑→保存）

三、审计日志

审计字段设计：

{
  "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": "callTool",
  "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 版本化：

{
  "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

版本协商：

• 客户端连接时声明支持的 schema 版本范围
• 服务端返回双方兼容的最新版本
• 不兼容时返回明确错误和升级指引

六、外部暴露安全加固

MCP从Demo到生产需要补齐五层安全加固。第一层认证授权：外部客户端用OAuth2，内部服务用API Key加HMAC签名，关键是工具级权限控制，高危工具如写数据库、发邮件需要额外授权。第二层会话管理：设置空闲超时和最长时长，支持心跳检测和断线重连，有状态的多步操作需要会话保持上下文。第三层审计日志：每次工具调用必须记录who/what/when/result四要素，高危操作全量记录参数，敏感信息脱敏。第四层限流防滥用：分网关级全局限流、客户端级令牌桶、工具级独立限流三层，再加载荷大小和执行时间限制。第五层Schema演进：工具接口版本化，遵循向后兼容原则，删除和修改走deprecated过渡期。整体思路是把传统API网关的治理能力搬到MCP协议上，同时针对AI场景加了工具权限分级和参数注入检测。

追问方向：

• “MCP 和 REST API 安全的核心区别？”→ MCP 工具由 LLM 自主选择调用，存在间接 Prompt Injection 风险（用户输入诱导 LLM 调用高危工具）；需要额外的工具权限管控层，不能像 REST API 一样只靠认证鉴权
• “工具执行超时怎么处理？”→ 设置执行超时阈值（如 30s），超时后返回 partial 结果或错误码；长耗时工具走异步模式（提交任务→轮询/回调获取结果），避免阻塞 Agent 主循环
• “如何防止 LLM 被 Prompt Injection 诱导调用危险工具？”→ 工具权限白名单（只开放必要工具）+ 高危工具（如删除/支付）强制人工审批 + 输出审查（检测 LLM 响应中是否包含可疑指令）
• “多租户场景下 MCP Server 怎么部署？”→ 共享 Server + 租户路由适合轻量级隔离（成本低），独立 Server per 租户适合强隔离要求（如金融/医疗）；选择取决于安全合规要求和成本预算
• “Schema 变更如何通知客户端？”→ 版本号递增 + listTools 响应中对废弃工具带 deprecated 标记和迁移指引 + changelog webhook 推送变更通知给订阅的客户端

易错点：

• ❌ “MCP是内部协议不需要认证”——一旦暴露给外部客户端，安全要求等同于公开API
• ❌ “限流只看QPS”——AI场景还要限Token消耗和执行时长
• ❌ “审计日志记录完整返回值”——返回值可能包含大量数据，应只记录摘要
• ❌ 忽略工具参数注入——LLM生成的SQL/命令可能被间接注入操控
• ✅ 核心思路：把MCP当成一个”由AI驱动的API网关”来治理