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

# AWS DevOps 代理安全
<a name="aws-devops-agent-security"></a>

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

## 多层安全
<a name="multi-layered-security"></a>

AWS DevOps 代理在多层实现安全性。即使向代理的 IAM 角色授予了更广泛的权限，代理也会强制执行自己的内部访问控制以限制其操作范围。例如，如果客户向代理的 IAM 角色添加了完整的 Amazon S3 访问 IAM 策略，则 AWS DevOps 代理将确保仅读取`AWSLogs`前缀之后的日志以进行故障排除。

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

## 代理空间
<a name="agent-spaces"></a>

代理空间是 AWS DevOps 代理中的主要安全边界。每个代理空间：
+ 使用自己的配置和权限独立运行
+ 定义代理可以访问哪些 AWS 账户和资源
+ 建立与第三方平台的连接

Agent Spaces 保持严格的隔离，以确保安全并防止跨不同环境或团队的意外访问。

## 区域处理和数据流
<a name="regional-processing-and-data-flow"></a>

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

### Amazon Bedrock 使用情况和跨区域推理
<a name="amazon-bedrock-usage-and-cross-region-inference"></a>

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

AWS DevOps 代理会将您的推理请求安全地路由到发出请求的地理区域内的可用计算资源，如下所示：
+ 来自欧盟的推理请求将在欧盟内部处理。
+ 来自美国的推理请求将在美国境内处理。
+ 来自澳大利亚的推理请求将在澳大利亚境内处理。
+ 来自日本境内的推理请求将在日本国内处理。
+ 如果推理请求来自未列出的区域，则默认情况下将在美国境内进行处理。
+ DevOps Agent 和 Bedrock 不受服务控制政策 (SCPs) 或 Control Tower 中将客户内容限制在特定区域的客户政策的影响
+ Bedrock 可能会使用您所在地理区域内的原始区域以外的区域来执行无状态推理，以优化性能和可用性

## Identity and access management
<a name="identity-and-access-management"></a>

### 身份验证方法
<a name="authentication-methods"></a>

AWS DevOps 代理提供了两种登录 AWS DevOps 代理空间 Web 应用程序的身份验证方法：
+ **AWS 身份中心集成** — 主要身份验证方法使用 OAuth 2.0，使用仅限 HTTP 的 Cookie 进行基于会话的身份验证。 AWS 身份中心可以通过标准的 OIDC 和 SAML 协议与外部身份提供商联合，包括 Okta、Ping Identity 和 Microsoft Entra ID 等提供商。此方法支持通过您的身份提供商进行多因素身份验证。 AWS Identity Center 的会话持续时间默认为最长 12 小时，并且可以配置为所需的持续时间。
+ **IAM 身份验证链接** — 另一种方法允许使用从现有 AWS 管理控制台会话中衍生的基于 JWT 的令牌从 AWS 管理控制台直接访问 Web 应用程序。此选项可用于在实现完整 Identity Center 集成之前评估 AWS DevOps 代理，以及在无法通过基于 Identity Center 的身份验证访问 AWS DevOps 代理 Web 应用程序时获得管理访问权限。会话限制在 10 分钟以内。

### IAM 角色
<a name="iam-roles"></a>

AWS DevOps 代理使用 IAM 角色来定义访问权限：
+ **主账户角色**-授予代理访问您在其中创建代理空间的 AWS 账户中的资源的访问权限以及次要账户角色的访问权限。
+ **次要账户角色**-授予代理访问连接到代理空间的其他 AWS 账户中的资源的权限。
+ **Web 应用程序角色**-授予用户在 Web 应用程序中访问 AWS DevOps 代理调查数据和结果的权限。

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

## 数据保护
<a name="data-protection"></a>

### 数据加密
<a name="data-encryption"></a>

AWS DevOps 代理对所有客户数据进行加密：
+ 静@@ **态加密**-所有数据均使用 AWS托管密钥加密。
+ **传输中的加密**-所有检索到的日志、指标、知识项目、工单元数据和其他数据在传输到代理的专用网络和外部网络时都经过加密。

### 数据存储和保留
<a name="data-storage-and-retention"></a>

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

### 个人身份信息 (PII)
<a name="personal-identifiable-information-pii"></a>

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

## 代理日志和审计日志
<a name="agent-journal-and-audit-logging"></a>

### 代理日记
<a name="agent-journal"></a>

事件调查和预防部门都维护详细的日志，这些日记包括：
+ 记录每一个推理步骤和采取的行动
+ 实现代理决策过程的完全透明
+ 一旦记录下来，代理就无法对其进行修改，从而最大限度地减少了诸如提示注入之类的攻击，使其无法隐藏重要操作
+ 包含 “调查” 页面上的所有聊天消息

### AWS CloudTrail 整合
<a name="aws-cloudtrail-integration"></a>

所有 AWS DevOps 代理 API 调用 AWS CloudTrail 均由主机 AWS 账户自动捕获。使用收集的信息 CloudTrail，您可以确定：
+ 向代理人提出的请求
+ 发出请求的 IP 地址
+ 发出请求的人员
+ 发出请求的时间

## 即时注射保护
<a name="prompt-injection-protection"></a>

当攻击者将恶意指令嵌入外部数据（例如网页或文档）中时，就会发生提示注入攻击，生成式 AI 系统稍后将处理这些指令。 AWS DevOps 作为其正常操作的一部分，Agent 本机会使用许多数据源，包括日志、资源标签和其他操作数据。 AWS DevOps 代理通过以下保护措施防止即时注入攻击，但重要的是要确保所有连接的数据源和用户对这些数据源的访问都是可信的。有关更多信息，请参见[分担责任模型](#aws-devops-agent-security)部分。

及时注射的保障措施：
+ **写入能力有限** — 除了打开工单和支持案例外，代理可用的工具无法改变资源。这样可以防止恶意指令修改您的基础设施或应用程序。
+ **账户边界强制执行** — AWS DevOps 代理只能在主账户和关联的次要 AWS 账户中分配给代理的角色所允许的边界内运作。代理无法访问或修改其配置范围之外的资源。
+ **AI 安全保护** — AWS DevOps 代理使用具有 AI 安全等级 3 (ASL-3) 保护的模型。这些保护措施包括分类器，这些分类器可在即时注入攻击影响代理行为之前对其进行检测和防止。
+ **不可变的审计跟踪** — 代理日志记录每一个推理步骤和采取的行动。记录日记条目后，代理就无法修改日记条目，从而防止提示注入攻击隐藏恶意行为。

虽然 AWS DevOps Agent 提供了针对即时注入攻击的多层保护，但某些配置可能会增加风险：
+ **自定义 MCP 服务器工具** — bring-your-own MCP 功能允许您向代理引入自定义工具，这可以为即时注入提供更多机会。自定义工具可能没有与原生 AWS DevOps 代理工具相同的安全控制，恶意指令可能会以意想不到的方式利用这些工具。有关更多信息，请参见[分担责任模型](#aws-devops-agent-security)部分。
+ **授权用户攻击** — 有权在 AWS 账户边界内或关联工具内操作的用户尝试攻击代理的几率更高。这些用户可能能够修改代理使用的数据源，例如日志或资源标签，从而更容易嵌入代理将要处理的恶意指令。

要降低这些风险，请执行以下操作：

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

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

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

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

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

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

## 集成安全
<a name="integration-security"></a>

AWS DevOps 代理支持多种集成类型，每种类型都有自己的安全模型：
+ **本机双向集成**-内置集成，可以向代理发送数据并从代理接收更新。这使用供应商的身份验证方法
+ **MCP 服务器** — 使用 OAuth 2.0 身份验证流程和 API 密钥与外部系统安全通信的远程模型上下文协议服务器。
+ **Webhook 触发器** — 来自远程服务（例如票证或可观测性系统）的调查触发器。Webhook 使用基于哈希的消息身份验证码 (HMAC) 来确保安全。
+ **出站通信** — 诸如 Slack 和票务系统之类的集成会从代理接收更新，但尚不支持双向通信。

### 注册提供商
<a name="registration-providers"></a>

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

以下工具使用账户级注册：
+ **GitHub**— 使用 OAuth 流程进行身份验证。在账户 GitHub 级别注册后，每个 Agent Space 都可以连接到 GitHub 组织内的特定存储库。
+ **Dynatrac** e — 使用 OAuth 令牌身份验证。在账户级别注册 Dynatrace 后，每个代理空间都可以连接到特定的 Dynatrace 环境或监控配置。
+ **Slack** — 使用 OAuth 令牌身份验证。在账户级别注册 Slack 后，每个 Agent Space 都可以连接到特定的 Slack 频道频道。
+ **Datadog** — 使用带有 OAuth 流程的 MCP 进行身份验证。在账户级别注册 Datadog 后，每个代理空间都可以连接到特定的 Datadog 监控资源。
+ **新遗物**-使用 API 密钥身份验证。在账户级别注册 New Relic 后，每个 Agent Space 都可以连接到特定的 New Relic 监控配置。
+ **Splunk** — 使用不记名令牌身份验证。在账户级别注册 Splunk 后，每个代理空间都可以连接到特定的 Splunk 数据源。
+ **GitLab**— 使用访问令牌身份验证。在账户 GitLab 级别注册后，每个 Agent Space 都可以连接到特定的 GitLab 存储库。
+ **ServiceNow**— 使用 OAuth 客户端 key/token 身份验证。在账户 ServiceNow 级别注册后，每个 Agent Space 都可以连接到特定的 ServiceNow 实例或工单队列。
+ **普通公众可访问的远程 MCP 服务器**-使用 OAuth 流程进行身份验证。在帐户级别注册远程 MCP 服务器后，每个代理空间都可以连接到该服务器公开的特定资源。

## 网络连接
<a name="network-connectivity"></a>

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

### 从 AWS DevOps 代理到您的系统的入站流量
<a name="inbound-traffic-from-aws-devops-agent-to-your-systems"></a>

AWS DevOps 代理启动与您的第三方系统和远程 MCP 服务器的出站连接，这些连接以入站流量形式到达您的基础架构。如何保护这些流量取决于您的工具托管方式：
+ **私有托管工具** — 如果您的工具可以从 AWS VPC 内访问，则可以使用 AWS DevOps 代理*私有连接*将流量隔离到 AWS 网络，并与公共 Internet 隔离。有关更多信息，请参阅 [连接到私人托管的工具](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)。
+ **公开托管的工具**-如果您的工具可通过公共 Internet 访问并使用 IP 许可名单或防火墙规则，则必须允许来自以下 AWS DevOps 代理源 IP 地址的入站流量：
  + 亚太地区（悉尼）(ap-southeast-2)
    + `13.237.95.197`
    + `13.238.84.102`
  + 亚太地区（东京）(ap-northeast-1)
    + `13.192.12.233`
    + `35.74.181.230`
    + `57.183.50.158`
  + 欧洲地区（法兰克福）(eu-central-1)
    + `18.158.110.140`
    + `52.57.96.160`
    + `52.59.55.56`
  + 欧洲地区（爱尔兰）(eu-west-1)
    + `34.251.85.24`
    + `52.30.157.157`
    + `52.51.192.222`
  + 美国东部（弗吉尼亚州北部）(us-east-1)
    + `34.228.181.128`
    + `44.219.176.187`
    + `54.226.244.221`
  + 美国西部（俄勒冈州）(us-west-2)
    + `34.212.16.133`
    + `52.89.67.212`
    + `54.187.135.61`

### 从您的 VPC 到 AWS DevOps 代理的出站流量
<a name="outbound-traffic-from-your-vpc-to-aws-devops-agent"></a>

对于从您的 AWS VPC 到 AWS DevOps 代理的出站流量（例如，使用[通过 Webhook 调用 DevOps 代理](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)），您可以使用 VPC 终端节点将此网络流量与 AWS 网络隔离。有关更多信息，请参阅 [VPC 终端节点 (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md)。

## 责任共担模式
<a name="shared-responsibility-model"></a>

### AWS 责任
<a name="aws-responsibilities"></a>

AWS 负责：
+ 维护代理检索到的数据的安全性
+ 保护可供代理使用的本机工具
+ 保护运行 AWS DevOps 代理的基础架构

### 客户责任
<a name="customer-responsibilities"></a>

客户负责：
+ 管理用户对代理空间的访问权限
+ 限制向代理提供输入的外部系统的可信用户的访问权限，例如生成日志、 CloudTrail 事件、票证等的服务和资源，这些服务和资源可能被用来尝试恶意提示注入。
+ 确保所有连接的数据源都有不太可能被用来尝试提示注入攻击的可信数据
+ 确保 bring-your-own MCP 服务器集成安全运行
+ 确保分配给代理的 IAM 角色范围正确
+ 在存储到可观测性日志和其他代理数据源中之前，先修改 PII 数据
+ 遵循建议的做法，即仅向连接的数据源（包括 bring-your-own MCP 服务器）授予只读权限

## 数据使用情况
<a name="data-usage"></a>

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

## 合规
<a name="compliance"></a>

在预览版中， AWS DevOps Agent 不符合 SOC 2、PCI-DSS、ISO 27001 或 FedRAMP 等标准。 AWS 稍后将宣布将提供哪些合规认证。