Model Context Protocol (MCP) 可标准化生成式 AI 代理连接到 AlloyDB for PostgreSQL 的方式。由于自主代理存在固有的风险,因此缓解提示注入等漏洞需要采用责任共担模式,将平台控制与安全应用设计相结合。
如需设计和部署使用 Google Cloud Model Context Protocol (MCP) 工具的 AI 应用,请遵循本指南中的最佳实践。
准备工作
使用 MCP 工具时,应用的安全状况取决于代理的互动模型。如需了解您对智能体的使用如何影响将智能体与 MCP 服务器集成相关的安全风险,请参阅 AI 安全与防护。
安全责任
作为客户,您有责任确保代理平台配置和运行的安全性。
遵循最小权限原则
使用范围最小的服务账号运行代理。这是第一层也是最关键的防御层。
- 专用身份:为每个使用 MCP 工具的唯一代理或应用创建单独的专用服务账号。请勿重复使用现有的 SA,尤其是那些具有广泛权限的 SA。
- 最小范围:仅向服务账号授予必要的 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 |
Firestore 安全规则 |
根据应用逻辑或请求用户上下文限制文档级或字段级访问权限。 |
Bigtable |
IAM 角色 |
Bigtable 通过 IAM 角色在项目级、实例级和表级提供精细的控制。 |
安全代理设计
仅限代理的模型需要强大的应用级防御机制来抵御提示注入攻击,此类攻击试图覆盖系统提示。如需了解详情,请参阅 AI 安全性。
将数据和用户输入视为不可信
将最终用户的输入内容或代理从外部来源(例如网页搜索结果或第三方文档)提取的数据视为不受信任。
实现操作选择模式
避免使用开放式规划和执行 架构,在这种架构中,系统将高级任务规范与机械执行分离。 请改用限制模型自由度的设计模式。
- 操作选择器模式:模型唯一的工作就是将用户请求转换为一小部分预定义的安全函数。操作逻辑是硬编码的,无法由 LLM 修改。这有助于使代理免受针对控制流的注入攻击。
- 双 LLM 模式:使用执行核心任务的主 LLM(操作 LLM)和预先过滤用户提示是否存在恶意意图并事后过滤操作 LLM 的输出是否存在未经授权的操作或数据泄露的高度安全次要 LLM(安全屏障 LLM)。
防止未经授权的工具链
智能体必须仅调用任务所需的工具。确保您的编排代码可防止出现以下情况:
- 动态工具:代理不得能够动态注册新工具或更改现有工具的权限。
- 许可名单强制执行:在代理的初始系统提示和后端代码中声明代理可以访问的函数或数据库表的许可名单。如需查看 Gemini CLI 示例,请参阅限制工具访问权限。
安全配置
AlloyDB 提供 Model Armor,可在平台级强制执行安全边界。您必须启用并配置这些设置。
启用 Model Armor
使用 Google Cloud 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
如需了解详情和示例,请参阅在 Google Cloud上为 MCP 配置 Model Armor 保护。
针对敏感数据操作强制执行最低安全阈值
借助 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 | 支持按需备份和自动备份。这些备份是完全受管理的,可以恢复到新表。 |
启用 Cloud Audit Logs
确保为 MCP 以及所有相关 Google Cloud 服务(例如 BigQuery、Cloud SQL、AlloyDB 和 Spanner)启用数据访问审核日志。默认情况下,系统仅启用管理员活动审核日志。数据访问审核日志会记录代理执行的每次读取和写入操作。如需了解详情,请参阅 MCP 的数据访问审核日志。
审核敏感操作
在 Cloud Logging 中配置提醒,以检测异常或高风险操作。日志浏览器查询可识别在 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:发起请求的最终用户的标识符。