通过 Model Context Protocol 确保代理互动安全性的最佳实践

Model Context Protocol (MCP) 可标准化生成式 AI 代理连接到 Cloud SQL for MySQL 的方式。 由于自主代理存在固有的风险,因此缓解提示注入等漏洞需要采用责任共担模式,将平台控制与安全应用设计相结合。
如需设计和部署使用 Cloud de Confiance by S3NS Model Context Protocol (MCP) 工具的 AI 应用,请遵循本指南中的最佳实践。

准备工作

使用 MCP 工具时,应用的安全性取决于代理的互动模型。如需了解您使用代理的方式如何影响将代理与 MCP 服务器集成相关的安全 风险,请参阅AI 安全性 。

安全责任

作为客户,您负责安全地配置和运行代理平台。

遵循最小权限原则

使用范围最小的服务帐号运行代理。这是第一层也是最关键的防御层。

  • 专用身份:为每个使用 MCP 工具的唯一代理或应用创建一个单独的专用服务帐号。请勿重复使用现有服务账号,尤其是具有广泛权限的服务账号。
  • 最小范围:仅向服务帐号授予必要的 Identity and Access Management (IAM) 角色,例如 alloydb.viewer,而不是 alloydb.admin。如果代理只需要对特定数据集的读取权限,请使用自定义 IAM 角色将访问权限限制为代理功能所需的绝对最小值。
  • 职责分离: 如果代理需要对数据具有读取权限,并且对日志或临时存储具有写入权限,请使用两个单独的服务账号:一个账号用于高风险数据访问权限(范围最小),另一个账号用于低风险操作任务。

使用数据库原生精细控制机制

为了实现最强大的防御,请将 IAM 角色与数据库本身提供的精细访问权限控制相结合。这样可以确保,即使攻击者入侵了代理的 IAM 令牌,损害范围也会受到数据库引擎内部权限的限制,例如阻止 DROP TABLE 命令。


产品

粒度控制机制

重点

Cloud SQL 和 AlloyDB

数据库级角色,例如 PostgreSQL 和 MySQL 中的 CREATE ROLE。

管理特定数据库实例和架构中的权限。

BigQuery

列级访问权限控制(使用政策标记)

即使在授权表中,也要限制代理对敏感列(例如 PII)的访问权限。

Spanner

精细访问权限控制(具有 GRANT/REVOKE 的数据库角色)

对表和列强制执行精确的读取/写入/更新权限。

Firestore

IAM 角色和 IAM 条件

使用 IAM 角色和 IAM 条件配置每个数据库的访问权限。

Bigtable

IAM 角色

Bigtable 通过项目级、实例级和表级的 IAM 角色提供精细控制。

Oracle Database@Google Cloud

IAM 角色

Oracle Database@Google Cloud 通过项目级层和资源级层的 IAM 角色提供精细控制。

安全代理设计

仅代理模型需要针对提示注入攻击提供强大的应用级防御,这些攻击试图替换系统提示。如需了解更多 信息,请参阅 AI 安全性和 安全性

将数据和用户输入视为不可信

将最终用户的输入或代理从外部来源(例如网页搜索结果或第三方文档)提取的数据视为不可信。

实现操作选择模式

避免使用开放式 计划和执行 架构,在这种架构中 系统将高级任务规范与机械执行分离。 请改用限制模型自由度的设计模式。

  • 操作选择器模式: 模型的工作仅是将用户请求转换为一小部分预定义的安全函数之一。操作逻辑是硬编码的,无法由 LLM 修改。这有助于使代理免受针对控制流的注入攻击。
  • 双 LLM 模式: 使用执行核心任务的主 LLM(操作 LLM)和预先过滤用户提示以查找恶意意图并事后过滤操作 LLM 的输出以查找未经授权的操作或数据泄露的辅助高安全 LLM(护栏 LLM)。

防止未经授权的工具链接

代理只能调用任务所需的工具。确保编排代码可防止以下情况:

  • 动态工具: 代理不得能够动态注册新工具或更改现有工具的权限。
  • 许可名单强制执行: 在代理的初始系统提示和后端代码中声明代理可以访问的函数或数据库表的许可名单。如需查看 Gemini CLI 示例,请参阅限制 工具访问权限

限制多租户数据库中的数据访问权限

execute_sql 等通用工具允许调用方执行数据库查询,这些查询可以读取 IAM 和数据库权限允许访问的任何数据。当您创建在没有可信人机协同的情况下访问多租户应用中的数据的代理时,可能需要进一步限制数据访问权限。

为了确保代理只能读取其有权访问的数据的子集,我们建议您使用 MCP Toolbox for Databases等框架创建自定义工具。如需了解详情,请参阅预构建工具与自定义工具

例如,假设您的数据库在 Orders 表中存储所有最终用户的订单。您正在开发一个与用户互动并可以查找其订单的聊天代理。聊天代理有权读取整个 Orders 表,但一个最终用户不得能够请求有关其他用户订单的信息。

在不安全的情况下,您仅为代理配备 execute_sql 工具,这会带来数据泄露的风险。恶意用户可以诱骗代理读取和返回其他用户的订单。 指示代理强制执行访问规则通常不足以保护数据。

在安全的情况下,您可以为代理提供更具体的自定义工具(例如 lookup_active_order),其中查询过滤器中用户的身份是在代理控制之外设置的。

安全配置

Cloud SQL for MySQL 提供 Model Armor,以在 平台级强制执行安全边界。您必须启用并配置这些设置。

启用 Model Armor

使用 gcloud CLI 在模型部署中启用 Model Armor。这会针对已知攻击媒介(例如注入和越狱)激活内置保护。

以下示例在 Vertex AI 端点上启用 Model Armor。

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

如需了解详情和示例,请参阅为 MCP 配置 Model Armor 保护 Cloud de Confiance

对敏感数据操作强制执行最低安全阈值

Model Armor 允许您对敏感数据操作(例如个人身份信息 (PII) 检测和去标识化)强制执行最低安全阈值。使用 Sensitive Data Protection DeidentifyTemplate 在将敏感信息返回给用户之前隐去或遮盖敏感信息,即使 模型遭到入侵也是如此。

以下是配置的概念示例:

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

在以下示例中,model_armor_config.json 可能会引用 DLP 模板:

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

审核和可观测性

了解代理操作对于突发事件后分析和检测遭到入侵的代理至关重要。

实现数据恢复策略

虽然 IAM 和数据库原生角色等分层控制旨在防止破坏性操作,但您必须制定恢复计划,以防这些防御措施失败。具有写入权限的遭到入侵或幼稚的代理(“仅代理”风险)可能会被诱骗执行 DROP TABLE 等破坏性命令或损坏数据。

针对这种情况的主要防御措施是制定强大的恢复策略。

几乎所有 Data Cloud 产品都提供数据恢复功能,无论是通过传统备份、时间点恢复 (PITR) 还是数据快照。 您负责启用和配置这些功能。

产品 备份和恢复机制
Cloud SQL 同时支持按需备份和自动备份,让您可以将实例恢复到之前的状态。它还支持时间点恢复 (PITR)。
AlloyDB 默认提供持续备份和恢复。这支持微秒级 PITR,让您可以将集群恢复到保留期内的任何时间点。
BigQuery 数据恢复通过“时间旅行”实现,让您可以访问和恢复过去 7 天内任何时间点的数据。如需长期保留,您可以创建表快照。
Spanner 同时支持按需备份和 PITR。
Firestore 支持自动备份,让您可以将数据库恢复到之前的状态。它还提供 PITR,以防止意外删除或写入。这两项功能默认处于停用状态。
Bigtable 支持按需备份和自动备份。这些备份是完全托管的,可以恢复到新表。
Oracle Database@Google Cloud 支持自动备份和 PITR。

启用 Cloud Audit Logs

确保为 MCP 以及所有相关 Cloud de Confiance 服务 (例如 BigQuery、Cloud SQL、AlloyDB、Firestore、Spanner 和 Oracle Database@Google Cloud)启用 数据访问 审核日志。默认情况下,仅启用管理员 活动审核日志。数据访问审核日志会记录代理执行的每个读取和写入操作。如需了解详情,请参阅 MCP 的数据 访问审核日志

审核敏感操作

在 Cloud Logging 中配置提醒,以检测异常或高风险操作。Logs Explorer 查询会识别在 Firestore 中执行 数据写入 操作的服务账号,例如,这是渗漏或破坏性攻击的常见目标:

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

使用特定于代理的日志记录

除了 Cloud Audit Logs 之外,还要确保应用代码记录每个代理决策的以下数据:

  • 工具执行: 调用的 MCP 工具。
  • 原始命令: LLM 生成的确切命令,例如 SQL 查询或文档路径。
  • 最终操作: 操作是执行(仅代理模型)还是获得批准(人工参与)。如需了解详情,请参阅了解 代理使用情况
  • 用户和会话 ID: 发起请求的最终用户的标识符。