概要
前回の記事ではAWS DevOps Agentの基本的な使い方やマルチアカウントでのインシデント調査を記載しました。今回は、DevOpsエージェントのセキュリティ面にフォーカスし、IAMロールの構成やアクセス制御の仕組みについて記載します。
DevOpsエージェントで利用するIAMロール
DevOpsエージェントでエージェントスペースを作成時に、デフォルト設定で進めていくとDevOpsAgentRole-AgentSpace-xxxxxxxxとDevOpsAgentRole-WebappAdmin-xxxxxxxxが作成されます。こちらのIAMロールの設定を確認しつつ、DevOpsエージェントからAWSリソースへアクセスする際と、ユーザーがウェブアプリケーションにアクセスする際の仕組みを確認していきます。
DevOpsエージェントからAWSリソースへのアクセス
DevOpsAgentRole-AgentSpace-xxxxxxxxはDevOpsエージェントがAWS環境を調査するための実行ロールです。こちらのIAMロールにはマネージドポリシーとインラインポリシーが含まれています。
マネージドポリシーAIDevOpsAgentAccessPolicyは、ほとんどが読み取り権限で構成されています。
読み取り以外の権限としては下記のような権限も含まれています。
-
support:CreateCase：AWSサポートケースの作成 -
logs:StartQuery、logs:StopQuery、logs:GetQueryResults：CloudWatch Logs Insightsのクエリ実行 -
cloudtrail:StartQuery、cloudtrail:LookupEvents：CloudTrailのクエリ実行
また、カスタマー管理ポリシーには下記のようなResource Explorerのサービスリンクロールの作成権限が付与されています。これはDevOpsエージェントがResource Explorerを利用してリソースの関連性やトポロジ情報を調査するためです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCreateServiceLinkedRoles",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": [
"arn:aws:iam::xxxxxxxxxxxx:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"
]
}
]
}
AWS DevOpsサービスが上記IAMロールを引き受ける際、権限ガードレールがセッションポリシーとして付与されます。このガードレールはエージェントが実行可能な権限の上限を定義するもので、IAMロール側に権限を追加してもガードレール側で許可されていなければ、エージェントはそのリソースにアクセスできません。
ガードレールに含まれており、インラインポリシーの追加によってオプトインできる権限はこちらのマニュアルに記載されています。例えばs3:GetObject、s3:ListBucketやDirect Connectに関する権限等が含まれます。それ以外の権限はガードレールに含まれないため、IAMロールに付与しても使用できません。
DevOpsエージェントのアクセス範囲をまとめると、まず前回の記事で記載したエージェントスペースによってアクセス対象のアカウントなどが限定されます。次に、リソースへのアクセス時にはAWS DevOpsサービスがIAMロールを引き受けますが、この際にガードレールがセッションポリシーとして渡されます。実効権限はIAMロールポリシーとガードレールの両方で許可された範囲（積集合）に限定されます。
ユーザーがウェブアプリケーションにアクセス
DevOpsAgentRole-WebappAdmin-xxxxxxxxはユーザーが利用するOperator Web Appを動作させるための管理・操作ロールです。こちらのIAMロールにはAWSマネージドポリシーAIDevOpsOperatorAppAccessPolicyがアタッチされており、チャットやインシデント調査等、ウェブアプリケーションを操作するための権限が付与されています。
ウェブアプリケーションを利用するユーザーは、基本的に共通のDevOpsAgentRole-WebappAdminをAWS DevOpsサービス経由で利用します。ユーザーが直接このロールをAssumeRoleするわけではありません。DevOpsAgentRole-WebappAdminの信頼ポリシーを確認すると下記のようにaidevops.amazonaws.comがロールを引き受けます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "xxxxxxxxxxxx"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:aidevops:ap-northeast-1:xxxxxxxxxxxx:agentspace/xxxxxxxxxxxx"
}
}
}
]
}
マネジメントコンソールにログイン後、IAM認証リンクからウェブアプリケーションにアクセスする場合、マネジメントコンソールの既存セッションから生成されたJWTベースのトークンを使用してウェブアプリケーションへの認証が行われます。ウェブアプリケーション内の操作はDevOpsAgentRole-WebappAdminの権限で実行されます。そのため、ウェブアプリケーション内の操作権限はすべてのユーザーで同一となります。
IAMユーザー側で権限を制御してエージェントスペース自体へのアクセス制限をかけることは可能です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "aidevops:*",
"Resource": "*"
}
]
}
まとめ
AWS DevOps Agentのセキュリティは、Agent Space・IAMロールポリシー・ガードレールによる多層防御で構成されています。エージェントに付与される権限はほぼ読み取り専用であり、書き込み操作はガードレールによってブロックされます。Operator Web Appへのユーザーアクセスは、AWS DevOpsサービスが共通のロールをAssumeRoleする仕組みのため、ウェブアプリケーション内の操作権限はユーザー間で差をつけることができません。アクセスの可否自体はIAMユーザー側のポリシーやIAM Identity Centerで制御可能です。運用の自動化を進めつつも、最小権限の原則が守られる設計になっている点は安心材料と言えます。