View a markdown version of this page

AWS DevOps 代理安全 - AWS DevOps 代理人
Multi-layered 安全代理空间区域处理和数据流Identity and access management数据保护代理日记和审计日志即时注射保护集成安全网络连接责任共担模式数据使用情况

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

AWS DevOps 代理安全

本文档提供有关 Ag AWS DevOps ent 的安全注意事项、数据保护、访问控制和合规性功能的信息。使用此信息来了解 AWS DevOps Agent 是如何设计以满足您的安全性和合规性要求的。

Multi-layered 安全

AWS DevOps 代理在多层实现安全性。即使为代理的 IAM 角色授予了更广泛的权限，该代理也会执行自己的内部访问控制以限制其操作范围。

我们建议在为 AWS DevOps 代理配置 IAM 权限时遵循最小权限原则，并在多层实现安全性。深度防御可确保任何一次配置错误都不会危及环境的安全。

代理空间

代理空间是 AWS DevOps 代理中的主要安全边界。每个代理空间：

  • 使用自己的配置和权限独立运行

  • 定义代理可以访问哪些 AWS 账户和资源

  • 建立与第三方平台的连接

代理空间保持严格的隔离，以确保安全性并防止不同环境或团队之间的意外访问。

区域处理和数据流

AWS DevOps 代理在全球范围内运营，具有区域处理能力。代理从配置的代理空间内获得访问权限的所有 AWS 账户的 AWS 区域检索操作数据。这种多区域跨账户数据收集可确保全面的事件分析，同时尊重推理处理的地理边界。

亚马逊 Bedrock 使用情况和跨区域推断

AWS DevOps 代理将自动选择您所在地理区域内的最佳区域来处理您的推理请求。这样可以最大限度地利用可用计算资源、模型可用性，并提供最佳的客户体验。您的数据将仅存储在创建代理空间的区域，但是，输入提示和输出结果可能会在该区域之外进行处理，如下表所述。所有数据都将通过 Amazon 的安全网络进行加密传输。

AWS DevOps Agent 会将您的推理请求安全地路由到发出请求的地理区域内的可用计算资源，如下所示：

  • 来自欧盟的推理请求将在欧盟内部处理。

  • 源自美国的推理请求将在美国境内处理。

  • 来自澳大利亚的推理请求将在澳大利亚境内处理。

  • 来自日本的推理请求将在日本境内处理。

  • 如果推理请求来自未列出的区域，则默认情况下将在美国境内进行处理。

  • DevOps 代理和 Bedrock 不受服务控制策略 (SCP) 或控制塔中将客户内容限制在特定区域的客户政策的影响

  • Bedrock 可能会使用您所在地理区域内源区域以外的区域进行无状态推断，以优化性能和可用性

针对特定区域的全球跨区域推理

对于以下区域，前面描述的基于地理位置的路径不适用。相反， AWS DevOps Agent 将在全球范围内自动选择最佳区域来处理您的推理请求。

  • 亚太地区（新加坡）– (ap-southeast-1)

  • 亚太地区（孟买）– (ap-south-1)

  • 南美洲（圣保罗）：(sa-east-1)

Identity and access management

身份验证方法

AWS DevOps 代理提供了两种身份验证方法来登录 AWS DevOps 代理空间 Web 应用程序：

  • AWS 身份中心集成 — 主要身份验证方法使用 OAuth 2.0，使用 Cookie 进行基于会话的身份验证。 HTTP-only AWS 身份中心可以通过标准的OIDC和SAML协议与外部身份提供商进行联合，包括Okta、Ping Identity和微软Entra ID等提供商。此方法支持通过您的身份提供商进行多因素身份验证。 AWS Identity Center 的默认会话持续时间最长为 12 小时，可以配置为所需的持续时间。

  • IAM 身份验证链接 — 另一种方法允许使用源自现有 AWS 管理控制台会话的 JWT-based 令牌从 AWS 管理控制台直接访问 Web 应用程序。此选项可用于在实现全面的身份中心集成之前评估 AWS DevOps 代理，以及在无法通过基于 Identity Center 的身份验证访问 AWS DevOps 代理 Web 应用程序时获得管理访问权限。会话限制在 10 分钟以内。

IAM 角色

AWS DevOps 代理使用 IAM 角色定义访问权限：

  • 主账户角色 -授予代理访问您创建代理空间的 AWS 账户中的资源的权限。

  • 辅助账户角色 -授予代理访问与代理空间关联的其他 AWS 账户中的资源的权限。

  • Web 应用程序角色 -授予用户访问 Web 应用程序中的 AWS DevOps 代理调查数据和调查结果的权限。

应按照最小权限原则配置这些角色，仅授予调查所需的必要只读权限。

数据保护

数据加密

AWS DevOps 代理加密所有客户数据：

  • 静态加密 — 所有数据均使用 AWS-managed 密钥加密。

  • 传输中加密 — 所有检索到的日志、指标、知识项目、票证元数据和其他数据在代理私有网络内和外部网络传输时均经过加密。

数据存储和保留

数据存储在创建代理空间的区域，而推理处理可能会在您所在的地理区域内进行，如前面的 Amazon Bedrock 使用情况部分所述。

个人身份信息 (PII)

AWS DevOps 在汇总调查、建议评估或聊天回复期间收集的数据时，代理不会过滤 PII 信息。建议先编辑 PII 数据，然后再存储到可观测性日志中。

代理日记和审计日志

代理日记

事件调查和预防职能部门都保留详细的日志，这些日志：

  • 记录每一个推理步骤和采取的行动

  • 让代理决策过程完全透明

  • 一旦记录下来，代理就无法修改，从而最大限度地减少了诸如提示注入之类的攻击以隐藏重要操作

  • 包括调查页面上的所有聊天消息

AWS CloudTrail 整合

所有 AWS DevOps 代理 API 调用均由 AWS CloudTrail 主机 AWS 账户自动捕获。使用收集的信息 CloudTrail，您可以确定：

  • 向代理人提出的请求

  • 发出请求的 IP 地址

  • 发出请求的人员

  • 发出请求的时间

对于 MCP 和 A2A 远程服务器连接，您可以查看 AWS DevOps 代理 CloudTrail 每次对访问令牌进行身份验证时记录AuthenticateAccessToken的事件，包括失败的身份验证。有关事件字段以及将身份验证与下游操作关联的更多信息，请参阅 “连接 DevOps 代理远程服务器” 中的 “可追溯性”。

即时注射保护

当攻击者在外部数据（例如网页或文档）中嵌入恶意指令时，就会发生即时注入攻击，生成式 AI 系统稍后会处理这些数据。 AWS DevOps 代理本身会消耗许多数据源作为其正常操作的一部分，包括日志、资源标签和其他操作数据。 AWS DevOps 代理通过以下保障措施防范即时注入攻击，但务必确保所有连接的数据源和用户对这些数据源的访问权限都是可信的。有关更多信息，请参阅责任共担模型部分。

即时注射保障措施：

  • 写入能力有限 — 代理可用的工具无法改变资源，开票和支持案例除外。这样可以防止恶意指令修改您的基础架构或应用程序。

  • 账户边界强制执行 — AWS DevOps 代理仅在主账户和关联辅助 AWS 账户中分配给代理的角色所允许的边界内运行。代理无法访问或修改其配置范围之外的资源。

  • AI 安全保护 — A AWS DevOps gent 使用具有 AI 安全级别 3 (ASL-3) 保护的模型，其中包括可检测和抵制即时注入尝试的内置分类器。该代理还使用 Amazon Bedrock Guardrails 提示攻击过滤器来检测和阻止即时注入和越狱尝试，以免它们影响代理行为。

  • 不可变的审计记录 — 代理日记记录每一个推理步骤和采取的行动。一旦记录下来，代理就无法修改日记条目，从而防止即时注入攻击隐藏恶意操作。

尽管 AWS DevOps Agent 提供多层保护，防止即时注入攻击，但某些配置可能会增加风险：

  • 自定义 MCP 服务器工具 — 自带 MCP 功能允许您向代理引入自定义工具，这可以为即时注入提供更多机会。自定义工具可能不具有与本机 AWS DevOps 代理工具相同的安全控制，恶意指令可能会以意想不到的方式使用这些工具。有关更多信息，请参阅责任共担模型部分。

  • 授权用户攻击 -被授权在 AWS 账户边界内或连接工具内操作的用户尝试攻击代理的可能性更高。这些用户可能能够修改代理使用的数据源，例如日志或资源标签，从而更容易嵌入代理将要处理的恶意指令。

为了减轻这些风险：

  1. 在将自定义 MCP 服务器部署到代理空间之前，请仔细检查和测试它们。

    1. 确保只允许他们执行只读操作

    2. 确认 MCP 服务器访问的外部工具的用户是可信实体，因为与 MCP 接口的 AWS DevOps 代理依赖于这些工具用户与代理之间建立的隐含信任关系 AWS DevOps

  2. 在授予用户访问向代理提供数据的系统的权限时应用最小权限原则

  3. 定期审核哪些 MCP 服务器连接到您的代理空间

  4. 由于从许可名单中的网址检索到的任何内容都可能试图操纵代理的行为，因此只在许可名单中包含可信来源。

集成安全

AWS DevOps 代理支持多种集成类型，每种类型都有自己的安全模型：

  • 原生双向集 Built-in 成 — 可以向代理发送数据并从代理接收更新的集成。这使用供应商的身份验证方法

  • MCP 服务器 — 使用 OAuth 2.0 身份验证流程和 API 密钥与外部系统安全通信的远程模型上下文协议服务器。

  • Webhook 触发器 — 来自远程服务（例如票证或可观测系统）的调查触发器。出于安全考虑，Webhook 使用 Hash-based 消息身份验证码 (HMAC) 签名或 API 密钥（持有者令牌）。

  • 出站通信 — Slack 和票务系统等集成从代理接收更新，但尚不支持双向通信。

注册提供商

一些外部工具在账户级别进行身份验证，并在账户中的所有代理空间之间共享。注册这些工具时，您需要在帐户级别进行一次身份验证，然后每个代理空间都可以连接到该注册连接中的特定资源。

以下工具使用账户级注册：

  • GitHub— 使用 OAuth 流程进行身份验证。在帐户 GitHub 级别注册后，每个 Agent Space 都可以连接到 GitHub 组织内的特定存储库。

  • Dynatrace — 使用 OAuth 令牌身份验证。在账户级别注册 Dynatrace 后，每个代理空间都可以连接到特定的 Dynatrace 环境或监控配置。

  • Slack — 使用 OAuth 令牌身份验证。在账户级别注册Slack后，每个代理空间都可以连接到特定的Slack频道频道。

  • Datadog — 使用带有 OAuth 流程的 MCP 进行身份验证。在账户级别注册 Datadog 后，每个代理空间都可以连接到特定的 Datadog 监控资源。

  • New Relic — 使用 API 密钥身份验证。在账户级别注册 New Relic 后，每个代理空间都可以连接到特定的 New Relic 监控配置。

  • Splunk — 使用持有者令牌身份验证。在账户级别注册 Splunk 后，每个代理空间都可以连接到特定的 Splunk 数据源。

  • GitLab— 使用访问令牌身份验证。在帐户 GitLab 级别注册后，每个代理空间都可以连接到特定的 GitLab 存储库。

  • ServiceNow— 使用 OAuth 客户端 key/token 身份验证。在账户 ServiceNow 级别注册后，每个代理空间都可以连接到特定的 ServiceNow 实例或票证队列。

  • 可供公众访问的远程 MCP 服务器 — 使用 OAuth 流程进行身份验证。在帐户级别注册远程 MCP 服务器后，每个代理空间都可以连接到该服务器暴露的特定资源。

网络连接

AWS DevOps 代理连接到您的第三方系统和远程 MCP 服务器以执行调查和其他操作。

来自的入站流量 AWS DevOps 为您的系统提供代理

AWS DevOps 代理启动与您的第三方系统和远程 MCP 服务器的出站连接，这些连接作为入站流量到达您的基础架构。如何保护这些流量取决于您的工具的托管方式：

  • 私有托管工具 -如果可以从 AWS VPC 内访问您的工具，则可以使用 AWS DevOps 代理私有连接来保持流量与 AWS 网络隔离，并远离公共互联网。有关更多信息，请参阅 连接到私人托管的工具。

  • 公开托管的工具 — 如果您的工具可通过公共互联网访问并使用 IP 许可清单或防火墙规则，则必须允许来自以下 AWS DevOps 代理源 IP 地址的入站流量：

    • 亚太地区（悉尼）(ap-southeast-2)

      • 13.237.95.197

      • 13.238.84.102

      • 52.64.174.242

      • 13.211.249.13

      • 15.134.235.54

      • 3.107.145.226

    • 亚太地区（东京）(ap-northeast-1)

      • 13.192.12.233

      • 35.74.181.230

      • 57.183.50.158

      • 13.114.228.89

      • 54.150.140.28

      • 46.51.224.121

    • 欧洲地区（法兰克福）(eu-central-1)

      • 18.158.110.140

      • 52.57.96.160

      • 52.59.55.56

      • 63.183.67.111

      • 63.184.95.132

      • 63.184.36.38

    • 欧洲地区（爱尔兰）(eu-west-1)

      • 34.251.85.24

      • 52.30.157.157

      • 52.51.192.222

      • 99.81.41.52

      • 54.246.170.103

      • 52.212.224.65

    • 美国东部（弗吉尼亚州北部）(us-east-1)

      • 34.228.181.128

      • 44.219.176.187

      • 54.226.244.221

      • 100.56.22.59

      • 3.234.39.4

      • 44.215.92.10

    • 美国西部（俄勒冈州）(us-west-2)

      • 34.212.16.133

      • 52.89.67.212

      • 54.187.135.61

      • 34.209.115.89

      • 44.224.219.86

      • 54.201.89.243

    • 南美洲（圣保罗）（sa-east-1）

      • 54.207.222.14

      • 54.232.201.242

      • 54.94.247.213

      • 54.94.50.36

      • 54.20.8.106

      • 52.67.155.119

    • 亚太地区（孟买）(ap-south-1)

      • 13.126.209.199

      • 13.234.6.24

      • 35.154.102.216

      • 13.200.172.217

      • 13.235.168.21

      • 13.206.231.7

    • 亚太地区（新加坡）(ap-southeast-1)

      • 18.139.13.125

      • 47.130.240.215

      • 54.179.238.173

      • 54.169.147.211

      • 52.77.189.96

      • 52.77.31.188

    • 加拿大（中部）(ca-central-1)

      • 3.96.5.29

      • 3.99.39.12

      • 99.79.90.221

      • 16.52.252.11

      • 16.52.242.49

      • 15.157.224.32

    • 欧洲地区（伦敦）(eu-west-2)

      • 13.42.228.66

      • 16.60.62.58

      • 35.176.240.10

      • 16.60.67.127

      • 3.9.91.248

      • 35.179.253.69

从您的 VPC 到的出站流量 AWS DevOps 代理人

对于从 AWS VPC 到 AWS DevOps 代理的出站流量（例如，使用通过 Webhook 调用 DevOps 代理），您可以使用 VPC 终端节点将此网络流量与 AWS 网络隔离。有关更多信息，请参阅 VPC 终端节点 (AWS PrivateLink)。

责任共担模式

AWS 责任

AWS 负责：

  • 维护代理检索的数据的安全性

  • 保护可供代理使用的本机工具

  • 保护运行 AWS DevOps 代理的基础架构

客户责任

客户负责：

  • 管理用户对代理空间的访问权限

  • 限制向代理提供输入的外部系统的可信用户的访问权限，例如生成日志、 CloudTrail 事件、票证等的服务和资源，这些服务和资源可能被用来尝试恶意提示注入。

  • 确保所有连接的数据源都有可信数据，这些数据不太可能被用来尝试即时注入攻击

  • 确保自带 MCP 服务器集成安全运行

  • 确保分配给代理的 IAM 角色范围正确

  • 在存储到可观测性日志和其他代理数据源之前编辑 PII 数据

  • 遵循仅向连接的数据源（包括自带 MCP 服务器）授予只读权限的推荐做法

数据使用情况

AWS 不使用代理数据、聊天消息或来自集成数据源的数据来训练模型或改进产品。 AWS DevOps Agent Space使用客户的产品内反馈来改善代理的响应和调查，但 AWS 不将其用于改善服务本身。

为了提供服务并评估其性能，我们可能会收集有关您使用 AWS DevOps 代理发布管理器的操作信号，例如基于您对发布准备情况审查评论的反馈的指标（例如您是否修复了已标记的问题、同意稍后解决问题、不同意该问题或实施了建议的代码更改）。