AWS IAMロールのAssumeRoleを徹底解説！信頼ポリシーの基本
AWS Identity and Access Management (IAM) は、AWSのリソースへのアクセスを安全に管理するための基盤となるサービスです。その中でも、「IAMロール」と、それに密接に関連する「AssumeRole」、そしてその動作を制御する「信頼ポリシー」は、AWS環境におけるアクセス管理の柔軟性とセキュリティを大きく左右する重要な要素です。
特に、アプリケーションやサービスが他のAWSサービスにアクセスする必要がある場合や、異なるAWSアカウント間でリソースを共有したい場合に、AssumeRoleは不可欠な機能となります。しかし、その仕組み、特に信頼ポリシーの記述方法や役割について、十分に理解していないと、意図しないアクセスを許してしまったり、逆に必要なアクセスができずに困ったりすることがあります。
この記事を読むことで、あなたは以下の点を深く理解できるようになります。
AWS環境をより安全かつ効率的に運用するために、ぜひ最後までお読みください。
まず、AWS IAMロールとは何かを明確にしておきましょう。IAMロールは、特定のアクセス権限を持ったIAMエンティティですが、IAMユーザーやグループとは異なり、特定の個人やアプリケーションに永続的に紐づくものではありません。代わりに、ロールは「引き受ける（Assume）」ことによって一時的にその権限を利用することを目的としています。
この特性により、以下のようなメリットが生まれます。
では、「AssumeRole」とは具体的にどのようなアクションでしょうか？ sts:AssumeRole は、AWS Security Token Service (STS) が提供するAPIアクションの一つです。このアクションを呼び出すことで、呼び出し元のエンティティ（ユーザー、サービスなど）は、指定されたIAMロールの一時的なセキュリティ認証情報（アクセスキーID、シークレットアクセスキー、セッショントークン）を取得できます。
この一時的な認証情報を使用することで、エンティティは、取得したロールに定義されているアクセス権限を行使して、AWSリソースに対する操作を実行できるようになります。
つまり、
sts:AssumeRole アクションを呼び出す。という流れになります。AssumeRoleは、この一連のプロセスの中心的な役割を担います。
さて、いよいよ本題である「信頼ポリシー」について深掘りしていきましょう。信頼ポリシーは、「そのIAMロールをどのようなエンティティが引き受けることを許可するか」を定義するポリシーです。これは、ロールを作成する際に必ず設定する必要がある、非常に重要な要素です。
提供されたJSONは、まさにこの信頼ポリシーの一例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com",
"ec2.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
このポリシーの各要素を見ていきましょう。
"Version": "2012-10-17"
これは、使用しているポリシー言語のバージョンを示します。現在、"2012-10-17" が最新かつ推奨されるバージョンです。通常、この値は変更する必要はありません。
"Statement": [...]
ポリシーの本体であり、1つ以上のステートメントを含む配列です。各ステートメントは、特定のアクセス許可または拒否のルールを定義します。提供された例では、1つのステートメントが含まれています。
"Effect": "Allow"
ステートメントの結果が「許可 (Allow)」なのか「拒否 (Deny)」なのかを指定します。信頼ポリシーでは、通常 Allow を使用して、特定のプリンシパルによるロールの引き受けを許可します。明示的な Deny は、明示的な Allow よりも優先されますが、信頼ポリシーで Deny を使うケースは稀です。
"Principal": { ... }
これが信頼ポリシーの最も重要な要素です。「誰が」このロールを引き受けることを許可するのかを指定します。Principal要素には、許可するエンティティのタイプと識別子を記述します。
Principalとして指定できる主なタイプは以下の通りです。
| Principal タイプ | 記述方法の例 | 説明 |
|---|---|---|
| AWSサービス | "Service": "サービス名.amazonaws.com"または "Service": ["サービス名1.amazonaws.com", "サービス名2.amazonaws.com"] | EC2やLambdaなどのAWSサービスがロールを引き受ける場合に使用します。サービス名を指定します。提供されたJSONはこのタイプです。 |
| AWSアカウント | "AWS": "arn:aws:iam::アカウントID:root"または "AWS": "arn:aws:iam::アカウントID:user/ユーザー名"または "AWS": "arn:aws:iam::アカウントID:role/ロール名" | 別のアカウントのユーザー、ルートユーザー、またはロールが、このロールを引き受けることを許可する場合に使用します。アカウントIDまたはIAMエンティティのARNを指定します。 |
| IAMユーザー/グループ | "AWS": "arn:aws:iam::あなたのアカウントID:user/ユーザー名"または "AWS": "arn:aws:iam::あなたのアカウントID:group/グループ名" | 同じアカウント内の特定のIAMユーザーやグループが、このロールを引き受けることを許可する場合に使用します。ユーザーまたはグループのARNを指定します。 |
| フェデレーテッドユーザー | "Federated": "arn:aws:iam::アカウントID:saml-provider/プロバイダー名"または "Federated": "arn:aws:iam::アカウントID:federated-user/ユーザー名"または "Federated": "cognito-identity.amazonaws.com" | SAML、WebID、またはCognitoなどを介して認証されたユーザーがロールを引き受ける場合に使用します。プロバイダーのARNなどを指定します。 |
提供されたJSONのPrincipalセクションは以下のようになっています。
"Principal": {
"Service": [
"lambda.amazonaws.com",
"ec2.amazonaws.com"
]
}
これは、AWS LambdaサービスとAWS EC2サービスが、この信頼ポリシーがアタッチされたロールを引き受けることを許可するという意味です。つまり、このロールはLambda関数やEC2インスタンスに割り当てて使用することを想定していることがわかります。
"Action": "sts:AssumeRole"
このステートメントで許可または拒否するAPIアクションを指定します。信頼ポリシーにおいては、必ず sts:AssumeRole アクションを指定します。これにより、「Principalで指定されたエンティティが、このロールのAssumeRoleアクションを実行すること」が許可されます。
信頼ポリシーには、特定の条件下でのみロールの引き受けを許可するように、Condition要素を含めることも可能です。例えば、特定の外部IDが提示された場合のみ許可する、特定のIPアドレスからのみ許可するなど、より詳細な制御が可能です。
"Condition": {
"StringEquals": {
"sts:ExternalId": "your-external-id"
}
}
この例は、AssumeRoleを呼び出す際に、呼び出し元がsts:ExternalIdコンテキストキーにyour-external-idという値を渡した場合にのみ、ロールの引き受けを許可するという条件を追加しています。これは、特にクロスアカウントアクセスを設定する際に、「Confused Deputy Problem (混乱した使節問題)」を防ぐために推奨されるセキュリティ対策です。
AssumeRoleは、AWS環境の様々なシナリオで活用されています。ここでは、代表的なユースケースをいくつかご紹介します。
これは提供されたJSONの信頼ポリシーが想定している典型的なユースケースです。
"Service": "ec2.amazonaws.com" や "Service": "lambda.amazonaws.com" を設定します。そして、EC2インスタンス起動時やLambda関数設定時にそのロールを割り当てます。EC2やLambdaサービスは、自動的にそのロールを引き受け、一時的な認証情報を使用して他のAWSサービスにアクセスします。複数のAWSアカウントを運用している場合、あるアカウントのユーザーやサービスが、別のアカウントのリソースにアクセスする必要が生じることがよくあります。
"AWS": "arn:aws:iam::アカウントAのID:root" または特定ユーザー/ロールのARN）。アカウントAのユーザーは、自分のアカウントの認証情報を使用して、アカウントBで作成したロールに対してsts:AssumeRoleを呼び出します。成功すると、アカウントBのロールの一時的な認証情報が付与され、その権限でアカウントBのS3バケットにアクセスできるようになります。普段は限定的な権限しか持たないIAMユーザーに、特定のタスクを実行するためだけに一時的に昇格した権限を与えたい場合があります。
sts:AssumeRoleを呼び出し、一時的な認証情報を取得します。タスク完了後、一時的な認証情報は有効期限が切れ、元の限定的な権限に戻ります。企業のActive Directoryや他のIDプロバイダー（IdP）とAWSを連携させ、企業ネットワークの認証情報でAWSにログインできるようにする場合にもAssumeRoleが利用されます。
IAMロールを理解する上で、混同しやすいのが「信頼ポリシー」と「アクセス権限ポリシー（または単にポリシー）」の違いです。この二つは役割が全く異なります。
| ポリシーの種類 | 役割 | 記述する内容 | アタッチ先 |
|---|---|---|---|
| 信頼ポリシー | **誰が** そのロールを 引き受けることを許可するかを定義 | Principal (許可するエンティティ)Action: "sts:AssumeRole"Effect: "Allow"Condition (任意) | IAMロール自体 |
| アクセス権限ポリシー (または単にポリシー) | ロールを引き受けたエンティティが **何ができるか** (どのリソースに対してどの操作を許可/拒否するか) を定義 | Action (許可/拒否するAPI操作)Resource (対象となるリソース)Effect: "Allow"/"Deny"Condition (任意)Principal は含まない (Identity-based Policyの場合) | IAMロール、IAMユーザー、IAMグループ |
要するに、
AssumeRoleが成功し、一時的な認証情報が付与された後、その認証情報を使用してAWSリソースにアクセスしようとする際に参照されるのが、ロールにアタッチされた「アクセス権限ポリシー」です。信頼ポリシーは、AssumeRoleの呼び出しが許可されるかどうかの判断にのみ使用されます。
信頼ポリシーは、IAMロールを作成または編集する際に設定できます。
IAMコンソールでロールを作成する際、最初のステップで「信頼されたエンティティタイプを選択」します。ここで、AWSサービス、別のアカウント、ウェブID、SAML 2.0フェデレーションなどを選択すると、それに合わせた信頼ポリシーのテンプレートが表示されます。その後、Principalの詳細（サービス名、アカウントID、プロバイダーARNなど）を指定します。
既存のロールの信頼ポリシーを変更するには、IAMコンソールで該当ロールを選択し、「信頼関係」タブを開き、「信頼ポリシーを編集」をクリックします。ここでJSON形式でポリシーを直接編集できます。
AWS CLI、SDK、あるいはCloudFormation、TerraformなどのInfrastructure as Code (IaC) ツールを使用しても、IAMロールとその信頼ポリシーを作成・管理できます。IaCを使用すると、ロールの設定をコードとして管理できるため、再現性やバージョン管理の面で大きなメリットがあります。
例えば、AWS CLIでロールを作成するコマンドは以下のようになります。
aws iam create-role --role-name MyTestRole --assume-role-policy-document file://trust-policy.json
ここで、trust-policy.json には、先ほど例に挙げたような信頼ポリシーのJSONを記述したファイルパスを指定します。
信頼ポリシーを設定する際には、以下のベストプラクティスを考慮しましょう。
ec2.amazonaws.com）を正確に指定します。sts:ExternalId条件を含めることを強く推奨します。これにより、混乱した使節問題を回避し、セキュリティを強化できます。AssumeRoleが期待通りに動作しない場合、いくつかの原因が考えられます。ここでは、よくある問題とそのトラブルシューティングのヒントをご紹介します。
信頼ポリシーの設定ミス:
sts:AssumeRole 以外になっている: 信頼ポリシーのActionは必ず sts:AssumeRole である必要があります。Deny になっている: 意図せず Deny ステートメントがPrincipalや条件にマッチしていないか確認してください。AssumeRoleを呼び出す側の権限不足:
sts:AssumeRole アクションを実行する権限を持っていない場合があります。AssumeRoleを呼び出す側のエンティティにアタッチされているアクセス権限ポリシーを確認し、目的のロールのARNに対する sts:AssumeRole の許可があるかを確認してください。サービスPrincipal（EC2, Lambdaなど）が信頼ポリシーで許可されている場合は、通常この問題は発生しませんが、ユーザーや別アカウントからのAssumeRoleでは確認が必要です。パスベースの名前付け:
/path/ のロール MyRole のARNは arn:aws:iam::アカウントID:role/path/MyRole となります。Permissions Boundary:
有効期限:
AssumeRoleの呼び出しは、AWS CloudTrailによってログ記録されます。AssumeRoleが失敗した場合、CloudTrailのイベント履歴を確認することで、誰が、いつ、どのロールに対してAssumeRoleを試行し、なぜ失敗したのか（例: AccessDenied エラー）といった詳細な情報を得ることができます。トラブルシューティングの際には、CloudTrailのログが非常に役立ちます。
AWS IAMロールのAssumeRole機能は、AWS環境におけるセキュアで柔軟なアクセス管理の要です。特に、アプリケーションやサービス間、あるいは異なるAWSアカウント間での権限委譲において、その真価を発揮します。
そして、そのAssumeRoleの動作を制御する鍵となるのが「信頼ポリシー」です。信頼ポリシーは、「誰がこのロールを引き受けることを許可するのか」を明確に定義します。Principal要素で許可するエンティティ（AWSサービス、アカウント、ユーザーなど）を指定し、Actionとして sts:AssumeRole を許可することで、AssumeRoleが可能になります。
信頼ポリシーと、ロールにアタッチされるアクセス権限ポリシーの違いを正しく理解することは、IAMロールを適切に設定・運用する上で非常に重要です。信頼ポリシーは「入り口の門番」、アクセス権限ポリシーは「部屋の中のルールブック」と覚えておきましょう。
この記事で解説した信頼ポリシーの構造、Principalの様々なタイプ、具体的なユースケース、そしてトラブルシューティングのヒントが、あなたのAWS環境におけるIAMロールとAssumeRoleの理解を深め、より安全で効率的なアクセス管理を実現するための一助となれば幸いです。
IAMはAWSセキュリティの根幹をなすサービスであり、その中でもロールとAssumeRoleは頻繁に利用されます。本記事で学んだ知識を活かして、あなたのAWS環境のセキュリティレベルをさらに向上させてください。