5月28日 06:28

MCP(Model Context Protocol)安全性设计有哪些关键机制?

OAuth 2.1 三方授权架构

MCP 规范(2025-06-18 版本)将安全模型建立在 OAuth 2.1 之上,采用经典的三方架构:

  • MCP Client 充当 OAuth 2.1 Client,负责发起授权请求
  • MCP Server 充当 OAuth 2.1 Resource Server,验证 Access Token 后提供资源
  • Authorization Server 负责用户认证、授权同意和令牌签发

授权流程从 Client 向 Server 发起连接开始。若 Server 要求认证,返回 401 Unauthorized 并在 WWW-Authenticate 头中提供 Protected Resource Metadata(PRM)文档地址。Client 通过 PRM 发现 Authorization Server 的端点信息,完成 Dynamic Client Registration(RFC 7591)后,引导用户浏览器打开 /authorize 端点完成登录和授权。授权码通过 PKCE 机制交换为 Access Token,后续请求携带 Bearer Token 访问资源。

对于本地 STDIO 传输,MCP 规范明确要求不走 OAuth 流程,而是通过环境变量注入凭证或复用第三方库的认证态,避免在本地进程间引入不必要的网络授权开销。

工具调用安全与 Tool Poisoning 防护

MCP 的核心能力是让 LLM 调用外部工具,这也带来了 Tool Poisoning 威胁——恶意 MCP Server 可以在 tool description 中嵌入 Prompt Injection 指令,操控 LLM 的行为。防护措施包括:

  • 工具描述哈希锁定:首次审批时记录 tool description 的哈希值,后续调用前校验哈希,防止"rug pull"式描述篡改
  • 工具版本钉扎:锁定已审批的 MCP Server 版本,避免自动更新引入恶意变更
  • 最小 Scope 授权:从最小的权限范围起步(如 mcp:tools),仅在业务需要时逐步提升,拒绝通配符 Scope
  • Human-in-the-loop:涉及写入、删除、发送等破坏性操作时,强制要求用户显式确认

沙箱隔离与权限最小化

每个 MCP Server 应运行在独立的容器化沙箱中,网络出口仅限白名单地址。关键实践:

  • 默认阻断出站 DNS,防止数据通过 DNS 隧道外泄
  • 文件系统挂载采用只读 + 白名单路径策略,Server 只能访问明确授权的目录
  • 设置执行超时和资源配额(CPU / 内存 / 磁盘),防止无限循环或资源耗尽
  • 使用 MCP Gateway 统一管理 Server 白名单、访问控制和集中日志

通信加密与证书验证

远程 MCP 连接强制使用 TLS,并实施完整的证书链验证和吊销检查(OCSP/CRL)。协议基于 JSON-RPC 2.0,在传输层之上不依赖额外的消息级加密。生产环境中建议:

  • 禁止自签名证书,所有证书必须由可信 CA 签发
  • 开启 HSTS 防止协议降级攻击
  • 定期轮换 TLS 证书,自动化证书管理采用 ACME 协议

输入验证与 Prompt Injection 防御

MCP 场景下的输入验证比传统 Web 应用更复杂,因为 LLM 的自然语言输入天然难以结构化验证。核心防御策略:

  • 参数 Schema 强校验:所有 tool input 必须声明 JSON Schema,Server 端严格按 Schema 验证,拒绝不合规参数
  • Prompt Injection 检测:在用户输入到达 LLM 前插入风险标签,识别越权指令、数据外泄企图等异常模式
  • 上下文隔离:不同来源的 Prompt 片段用隔离标记包裹,防止跨上下文的指令注入
  • 命令执行白名单:禁止 LLM 直接执行 Shell 命令,必须通过预定义的工具接口间接操作

审计日志与异常监控

MCP 的安全审计要求记录每一次工具调用的完整上下文:

  • 工具名称、调用参数、LLM 决策过程、返回结果均需记录
  • 每条日志携带 Correlation ID,支持跨 Server 调用链的端到端追踪
  • 日志推送至 SIEM 系统,配合规则引擎实时检测异常行为
  • 错误消息禁止泄露敏感信息(Token、密钥、内部路径),统一返回脱敏后的安全提示

数据隐私与合规

MCP 规范在数据层面强调用户同意和最小暴露原则:

  • Host 在向 Server 暴露用户数据前必须获得用户明确同意
  • Server 不得在未授权情况下将资源数据传输给第三方
  • 日志中的敏感字段(API Key、Token、个人身份信息)必须脱敏处理
  • 提供与 GDPR、CCPA、ISO 27001 等标准的合规映射能力,辅助生成评估报告

面试追问

Q: MCP 的 OAuth 2.1 授权和传统 Web 应用的 OAuth 有什么区别?

MCP 中 Server 同时承担 Resource Server 角色,Client 需要通过 Protected Resource Metadata(RFC 9728)发现 Authorization Server,而非硬编码授权端点。此外 MCP 强制使用 PKCE、支持 Dynamic Client Registration,且本地 STDIO 传输完全不走 OAuth 流程,改用环境变量注入凭证——这是与传统 Web OAuth 最大的架构差异。

Q: 如果 MCP Server 被植入恶意 tool description,如何检测和防御?

检测层面,通过 tool description 哈希比对发现描述被篡改,配合 SIEM 实时监控异常工具调用模式。防御层面,首次审批时锁定描述哈希和 Server 版本,运行时采用最小 Scope 策略限制工具权限,破坏性操作强制 Human-in-the-loop 确认,同时通过沙箱隔离限制 Server 的实际执行能力。

标签:MCP