翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS アカウントでのエージェントアクセスの制限
AWS DevOps エージェントは IAM ロールを使用して、インシデント調査と予防的評価中に AWS リソースを検出して記述します。これらのロールにアタッチされた IAM ポリシーを設定することで、エージェントが持つアクセスレベルを制御できます。アプリケーショントポロジには、エージェントがアクセスできるものがすべて表示されるわけではありません。IAM ポリシーは、エージェントがアクセスできる AWS サービス APIsとリソースを実際に制限する唯一の方法です。
## AWS DevOps エージェントの IAM ロールについて
AWS DevOps エージェントは IAM ロールを使用して、次の 2 種類のアカウントのリソースにアクセスします。
+ **プライマリアカウントロール** – エージェントスペースを作成する AWS アカウントのリソースへのアクセス権をエージェントに付与します。
+ **セカンダリアカウントロール** – エージェントスペースに接続する追加の AWS アカウントのリソースへのアクセス権をエージェントに付与します。
どちらのタイプのアカウントでも、エージェントがアクセスできる AWS サービスを制限し、それらのサービス内の特定のリソースへのアクセスを制限し、エージェントが操作できるリージョンを制御できます。
## アクセス許可ガードレールについて
AWS DevOps Agent は、 AWS リソースにアクセスするときに作成するすべてのセッションにアクセス許可ガードレールを適用します。このガードレールは上限として機能し、IAM ロールに付与するアクセス許可に関係なく、エージェントが使用できるアクセス許可の最大セットを定義します。
### 仕組み
エージェントは IAM ロールを引き受けると、その[セッションの有効なアクセス許可を制限するセッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)を渡します。有効なアクセス許可は、次の共通部分です。
1. **IAM ロールポリシー** — ロールにアタッチする管理ポリシーとインラインポリシー。
1. **アクセス許可ガードレール** — AWS DevOps Agent が継承ロール時に適用するセッションポリシー。
有効にするには、アクセス許可が両方のレイヤーに存在する必要があります。ガードレールに含まれていないアクセス許可をロールに追加した場合、エージェントはそのアクセス許可を使用できません。
### デフォルトのアクセス許可
`AIDevOpsAgentAccessPolicy` 管理ポリシーは、エージェントが調査に使用するデフォルトの読み取り専用アクセス許可のセットを提供します。これらのアクセス許可はガードレールに含まれているため、追加の設定なしで動作します。
### デフォルトを超えるアクセス許可の拡張
AWS DevOps エージェントは、デフォルトの マネージドポリシー以外の追加のアクセス許可の厳選されたセットをサポートします。これらのアクセス許可はガードレールに含まれていますが、デフォルトでは有効になっていません。これらを使用するには、特定のアクセス許可をインラインポリシーとしてロールに追加します。
たとえば、エージェントが調査中に S3 バケットからオブジェクトを読み取れるようにするには、インラインポリシーをロールに追加します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-application-bucket",
"arn:aws:s3:::my-application-bucket/*"
]
}
]
}
```
`s3:GetObject` および `s3:ListBucket`はガードレールに含まれているため、このインラインポリシーが有効になります。最小特権の原則に従って`Resource`、 を特定のバケットにスコープできます。
### サポートされている追加のアクセス許可
次のアクセス許可はガードレールに含まれており、インラインポリシーとしてロールに追加することで有効にできます。これらはデフォルトでは付与されません。明示的にオプトインする必要があります。
| サービス | アクション | ユースケース |
| --- | --- | --- |
| Amazon S3 | s3:GetObject, s3:ListBucket | S3 に保存されているアプリケーションデータ、ログ、または設定の読み取り |
| AWS Direct Connect | directconnect:DescribeConnections, directconnect:DescribeDirectConnectGatewayAssociations, directconnect:DescribeDirectConnectGateways, directconnect:DescribeLags, directconnect:DescribeVirtualInterfaces | ネットワーク接続の問題を調査する |
**注:** 新機能が AWS DevOps エージェントに追加されると、このリストは時間の経過とともに拡張される可能性があります。ここに記載されていないアクセス許可や `AIDevOpsAgentAccessPolicy`管理ポリシーに記載されていないアクセス許可は、ガードレールによってブロックされます。
### ガードレールによってブロックされるアクセス許可
ガードレールにないアクセス許可をロールに追加した場合、エージェントはそのアクセス許可を使用できません。これは設計上のものです。ガードレールは、ロールが許可する場合でも、エージェントが意図した範囲外のアクションを実行できないようにします。
たとえば、`s3:PutObject`、、 `ec2:TerminateInstances`などの書き込みオペレーション`dynamodb:DeleteItem`はガードレールに含まれません。ロールがこれらのアクセス許可を付与しても、エージェントはこれらのアクションを実行できません。
### 概要
| レイヤー | 誰がコントロールするか | 目的 |
| --- | --- | --- |
| IAM ロールポリシー | You | エージェントが何を実行できるようにするかを定義する |
| アクセス許可ガードレール | AWS DevOps エージェント | エージェントが実行できる最大数を定義します。 |
| 有効なアクセス権限 | 両方の交差 | エージェントが実際にできること |
このモデルにより、エージェントは明確に定義されたセキュリティ境界内で動作し、特定のユースケースに合わせて機能を柔軟に拡張できます。
## リソースの境界の選択
リソースアクセスを制限する場合は、エージェントがアプリケーションインシデントを正常に調査するための十分なアクセス許可を含める必要があります。これには、以下が含まれます。
+ エージェントがモニタリングおよび調査する必要がある対象範囲内のアプリケーションのすべてのリソース
+ これらのアプリケーションが依存するすべてのサポートインフラストラクチャ
インフラストラクチャのサポートには以下が含まれます。
+ ネットワークコンポーネント (VPCs、サブネット、ロードバランサー、API ゲートウェイ)
+ データストア (データベース、キャッシュ、オブジェクトストレージ)
+ コンピューティングリソース (EC2 インスタンス、Lambda 関数、コンテナ)
+ サービスのモニタリングとログ記録 (CloudWatch、CloudTrail)
+ アクセス許可を理解するために必要な Identity and Access Management リソース
アクセスを狭く制限しすぎると、エージェントは定義された境界外のサポートインフラストラクチャに起因する根本原因を特定できない可能性があります。
## サービスアクセスの制限
エージェントのロールにアタッチされている IAM ポリシーを変更することで、エージェントがアクセスできる AWS サービスを制限できます。カスタムポリシーを作成するときは、次のベストプラクティスに従ってください。
+ **読み取り専用アクセス許可の付与** – エージェントは調査中にリソース設定、メトリクス、ログを読み取る必要があります。エージェントがリソースを変更または削除できるようにするアクセス許可を付与することは避けてください。
+ **必要なサービスの制限** – アプリケーションに関連するリソースを含む AWS サービスのみを含めます。たとえば、アプリケーションが Amazon RDS を使用していない場合は、ポリシーに RDS アクセス許可を含めないでください。
+ **ワイルドカードの代わりに特定のアクションを使用する** – アクセス`service:*`許可を付与する代わりに、 `cloudwatch:GetMetricData`や などの個々のアクションを指定します`ec2:DescribeInstances`。
特定のサービスに制限するポリシーの例:
```
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"logs:GetLogEvents",
"logs:FilterLogEvents",
"ec2:DescribeInstances",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration"
],
"Resource": "*"
}
]
}
```
## リソースアクセスの制限
エージェントをサービス内の特定のリソースに制限するには、IAM ポリシーでリソースレベルのアクセス許可を使用します。これにより、特定のパターンに一致するリソースにのみアクセス権を付与できます。
**リソース ARN パターンの使用:**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:GetFunction",
"lambda:GetFunctionConfiguration"
],
"Resource": "arn:aws:lambda:*:*:function:production-*"
}
]
}
```
この例では、「production-」で始まる名前の Lambda 関数にのみアクセスするようにエージェントを制限します。
**タグベースの制限の使用:**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
}
]
}
```
この例では、エージェントが でタグ付けされた EC2 インスタンスのみにアクセスするように制限しています`Environment=production`。
## リージョンアクセスの制限
エージェントがアクセスできる AWS リージョンを制限するには、IAM ポリシーで `aws:RequestedRegion`条件キーを使用します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"lambda:Get*",
"cloudwatch:Get*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": [
"us-east-1",
"us-west-2"
]
}
}
}
]
}
```
この例では、us-east-1 および us-west-2 リージョンのリソースにのみアクセスするようにエージェントを制限します。
## カスタム IAM ポリシーの作成
エージェントスペースを作成するとき、またはセカンダリアカウントを追加するときに、ポリシーテンプレートを使用してカスタム IAM ロールを作成するオプションがあります。これにより、最小特権の原則を実装できます。
**エージェントスペースを作成する場合**
AWS マネジメントコンソールの DevOps エージェントコンソールから..。
+ **ポリシードキュメントを使用して新しい DevOps エージェントロールを作成し**、手順に従います。
**エージェントスペースを編集する場合**
AWS マネジメントコンソールの DevOps エージェントコンソールから..。
+ **機能**タブを選択する
+ **クラウド**セクションから編集するセカンダリアカウントを選択し、編集をクリックします
+ **テンプレートを使用して新しい DevOps エージェントポリシーを作成し**、手順に従います。
## カスタムポリシーのベストプラクティス
+ **読み取り専用アクセス許可のみを付与する** – リソースの変更または削除を許可するアクセス許可は避けてください
+ **可能な場合はリソースレベルのアクセス許可を使用する** — ARN パターンまたはタグを使用して特定のリソースへのアクセスを制限する
+ **アクセス許可の定期的なレビューと監査** – エージェントの IAM ポリシーを定期的にレビューして、セキュリティ要件に合致していることを確認します。