

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS DevOps エージェントセキュリティ
<a name="aws-devops-agent-security"></a>

このドキュメントでは、 AWS DevOps Agent のセキュリティ上の考慮事項、データ保護、アクセスコントロール、コンプライアンス機能について説明します。この情報を使用して、 AWS DevOps Agent がセキュリティおよびコンプライアンス要件を満たすように設計されている方法を理解します。

## マルチレイヤーセキュリティ
<a name="multi-layered-security"></a>

AWS DevOps Agent は、複数のレイヤーでセキュリティを実装します。より広範なアクセス許可がエージェントの IAM ロールに付与されている場合でも、エージェントは独自の内部アクセスコントロールを適用してアクションの範囲を制限します。

 AWS DevOps Agent の IAM アクセス許可を設定し、複数のレイヤーにセキュリティを実装するときは、最小特権の原則に従うことをお勧めします。多層防御により、単一の設定ミスによって環境のセキュリティが損なわれることはありません。

## エージェントスペース
<a name="agent-spaces"></a>

エージェントスペースは、 AWS DevOps エージェントの主要なセキュリティ境界として機能します。各エージェントスペース:
+ 独自の設定とアクセス許可で独立して動作します
+ エージェントがアクセスできる AWS アカウントとリソースを定義します。
+ サードパーティープラットフォームへの接続を確立します

エージェントスペースは、セキュリティを確保し、さまざまな環境やチーム間の意図しないアクセスを防ぐために、厳密な分離を維持します。

## リージョン処理とデータフロー
<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 Agent は、次のように、推論リクエストをリクエスト元の地理的領域内の利用可能なコンピューティングリソースに安全にルーティングします。
+ 欧州連合を起点とする推論リクエストは、欧州連合内で処理されます。
+ 米国を起点とする推論リクエストは、米国内で処理されます。
+ オーストラリアを起点とする推論リクエストは、オーストラリア内で処理されます。
+ 日本国内からの推論リクエストは、日本国内で処理されます。
+ 推論リクエストがリストされていないエリアから発信された場合、デフォルトで米国内で処理されます。
+ DevOps エージェントと Bedrock は、顧客コンテンツを特定のリージョンに制限するサービスコントロールポリシー (SCPsまたは Control Tower の顧客ポリシーの影響を受けません。
+ Bedrock は、パフォーマンスと可用性を最適化するために、地域内の発信元リージョン以外のリージョンを使用してステートレス推論を実行する場合があります。

## ID とアクセス管理
<a name="identity-and-access-management"></a>

### 認証方法
<a name="authentication-methods"></a>

AWS DevOps エージェントには、 AWS DevOps エージェントスペースウェブアプリにログインするための 2 つの認証方法が用意されています。
+ **AWS アイデンティティセンターの統合** – プライマリ認証方法では、HTTP 専用 Cookie を使用したセッションベースの認証で OAuth 2.0 を使用します。 AWS アイデンティティセンターは、Okta、Ping Identity、Microsoft Entra ID などのプロバイダーを含む標準の OIDC および SAML プロトコルを通じて外部 ID プロバイダーとフェデレーションできます。このメソッドは、ID プロバイダーを介した多要素認証をサポートします。 AWS Identity Center はデフォルトで最大 12 時間のセッション期間に設定され、希望する期間に設定できます。
+ **IAM 認証リンク** – 別の方法では、既存の AWS マネジメントコンソールセッションから派生した JWT ベースのトークンを使用して、 AWS マネジメントコンソールからウェブアプリケーションに直接アクセスできます。このオプションは、完全な Identity Center 統合を実装する前に AWS DevOps エージェントを評価する場合や、Identity Center ベースの認証を通じて AWS DevOps Agent ウェブアプリケーションにアクセスできなくなった場合に管理アクセスを取得する場合に便利です。セッションは 10 分に制限されています。

### IAM ロール
<a name="iam-roles"></a>

AWS DevOps エージェントは IAM ロールを使用してアクセス許可を定義します。
+ **プライマリアカウントロール** – エージェントスペースを作成する AWS アカウントのリソースへのアクセスと、セカンダリアカウントロールへのアクセスをエージェントに許可します。
+ **セカンダリアカウントロール** – エージェントスペースに接続された追加の AWS アカウントのリソースへのアクセス権をエージェントに付与します。
+ **ウェブアプリロール** – ウェブアプリの 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 Agent は、調査、レコメンデーション評価、またはチャットレスポンス中に収集されたデータを要約する際に PII 情報をフィルタリングしません。PII データは、オブザーバビリティログに保存する前に編集することをお勧めします。

## エージェントジャーナルと監査ログ記録
<a name="agent-journal-and-audit-logging"></a>

### エージェントジャーナル
<a name="agent-journal"></a>

Incident Investigation and Prevention 機能はいずれも、次のような詳細なジャーナルを維持します。
+ すべての推論ステップと実行されたアクションをログに記録する
+ エージェントの意思決定プロセスに完全な透明性を持たせる
+ エージェントが一度記録すると変更できないため、プロンプトインジェクションなどの攻撃が重要なアクションを非表示にできない
+ 調査ページからすべてのチャットメッセージを含める

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

すべての AWS DevOps エージェント API コールは、ホスティング AWS アカウント内の AWS CloudTrail によって自動的にキャプチャされます。CloudTrail によって収集されたデータを使用して、以下の情報を判断できます。
+ エージェントに対して行われたリクエスト
+ リクエストが行われた IP アドレス
+ リクエストを行ったユーザー
+ リクエストが行われた時刻

## プロンプトインジェクション保護
<a name="prompt-injection-protection"></a>

プロンプトインジェクション攻撃は、攻撃者が生成 AI システムが後で処理するウェブページやドキュメントなどの外部データに悪意のある指示を埋め込むときに発生します。 AWS DevOps Agent は、ログ、リソースタグ、その他の運用データなど、通常のオペレーションの一環として多くのデータソースをネイティブに消費します。 AWS DevOps Agent は、以下の保護手段を通じてプロンプトインジェクション攻撃から保護しますが、接続されているすべてのデータソースと、それらのデータソースへのユーザーアクセスが信頼できることを確認することが重要です。詳細については、[「 責任共有モデル](#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 とインターフェイスする AWS DevOps エージェントは、これらのツールユーザーと DevOps エージェントの間に確立された暗黙的な信頼関係に依存するため、MCP サーバーによってアクセスされる外部ツールのユーザーが信頼されたエンティティであることを確認します AWS DevOps 

1. エージェントにデータを提供するシステムへのアクセス権をユーザーに付与するときは、最小特権の原則を適用します。

1. エージェントスペースに接続されている MCP サーバーを定期的に監査する

1. 許可リストに登録された URLs から取得したコンテンツは、エージェントの動作を操作しようとする可能性があるため、許可リストには信頼できるソースのみを含めます。

## 統合セキュリティ
<a name="integration-security"></a>

AWS DevOps Agent は複数の統合タイプをサポートし、それぞれに独自のセキュリティモデルがあります。
+ **ネイティブ双方向統合** – エージェントにデータを送信し、エージェントから更新を受信できる組み込み統合。これにより、ベンダーの認証方法が使用されます。
+ **MCP サーバー** – OAuth 2.0 認証フローと API キーを使用して外部システムと安全に通信するリモートモデルコンテキストプロトコルサーバー。
+ **Webhook トリガー** – チケットやオブザーバビリティシステムなどのリモートサービスからの調査トリガー。ウェブフックは、セキュリティにハッシュベースのメッセージ認証コード (HMAC) を使用します。
+ **アウトバウンド通信** – Slack やチケットシステムなどの統合はエージェントから更新を受け取りますが、双方向通信はまだサポートされていません。

### 登録プロバイダー
<a name="registration-providers"></a>

一部の外部ツールはアカウントレベルで認証され、アカウント内のすべてのエージェントスペース間で共有されます。これらのツールを登録すると、アカウントレベルで 1 回認証され、各エージェントスペースはその登録された接続内の特定のリソースに接続できます。

以下のツールは、アカウントレベルの登録を使用します。
+ **GitHub** – OAuth フローを認証に使用します。アカウントレベルで GitHub を登録すると、各エージェントスペースは 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 クライアントキー/トークン認証を使用します。アカウントレベルで ServiceNow を登録すると、各エージェントスペースは特定の ServiceNow インスタンスまたはチケットキューに接続できます。
+ **一般公開アクセス可能なリモート MCP サーバー** – OAuth フローを認証に使用します。アカウントレベルでリモート MCP サーバーを登録すると、各エージェントスペースはそのサーバーによって公開されている特定のリソースに接続できます。

## ネットワーク接続
<a name="network-connectivity"></a>

AWS DevOps Agent は、サードパーティーのシステムとリモート MCP サーバーに接続して、調査やその他のオペレーションを実行します。

### AWS DevOps エージェントからシステムへのインバウンドトラフィック
<a name="inbound-traffic-from-aws-devops-agent-to-your-systems"></a>

AWS DevOps Agent は、サードパーティーシステムとリモート MCP サーバーへのアウトバウンド接続を開始し、インフラストラクチャへのインバウンドトラフィックとして到着します。このトラフィックを保護する方法は、ツールのホスト方法によって異なります。
+ **プライベートにホストされたツール** – ツールが AWS VPC 内から到達可能な場合は、 AWS DevOps Agent の*プライベート接続*を使用して、トラフィックを AWS ネットワークに隔離し、パブリックインターネットから切り離すことができます。詳細については、「[プライベートにホストされたツールへの接続](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)」を参照してください。
+ **パブリックにホストされたツール** – ツールがパブリックインターネット経由で到達可能で、IP 許可リストまたはファイアウォールルールを使用する場合は、次の AWS DevOps エージェントソース IP アドレスからのインバウンドトラフィックを許可する必要があります。
  + アジアパシフィック (シドニー) (ap-southeast-2)
    + `13.237.95.197`
    + `13.238.84.102`
    + `52.64.174.242`
  + アジアパシフィック (東京) (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 データを編集する
+ Bringbring-your-own MCP サーバーなど、接続されたデータソースに読み取り専用アクセス許可のみを付与するという推奨プラクティスに従う

## データ使用量
<a name="data-usage"></a>

AWS は、モデルをトレーニングしたり製品を改善したりするために、エージェントデータ、チャットメッセージ、または統合データソースからのデータを使用しません。 AWS DevOps エージェントスペースは、顧客の製品内フィードバックを使用してエージェントの応答と調査を改善しますが、サービス自体の改善には使用 AWS しません。