どーも！shihopowerです！
連載最終回です。ここまでの3本でIAMの全体像・SCP・RCP・アクセス許可の境界・セッションポリシーを整理してきました。
今回はAssumeRoleの仕組みを深掘りしたうえで、冒頭エピソードの「あのとき何をすればよかったのか」に答えます。
この記事で扱うこと
- AssumeRoleとは何か
- 4つの代表的な使用シナリオ
- AssumeRoleが満たすセキュリティのベストプラクティス
- EC2へのロールアタッチの正しい構造
- 冒頭エピソードの回答：研修環境の権限設計
- セキュリティのベストプラクティスまとめ
1. AssumeRoleとは何か
AssumeRole はAWS STS（Security Token Service）のAPIオペレーションです。IAMロールを「引き受けて」、そのロールの権限で操作できる一時的なセキュリティ認証情報を取得します。
返ってくる認証情報の中身
AssumeRole を呼び出すと以下の3点セットが返ってきます。
・アクセスキーID
・シークレットアクセスキー
・セッショントークン
この3点を使ってAWSリソースに対してAPIコールを行います。認証情報には有効期限があり（最短15分・最長12時間・デフォルト1時間）、期限が切れると自動的に無効になります。
信頼ポリシーで「誰が引き受けられるか」を定義する
ロールを引き受けるには、そのロールの信頼ポリシー（リソースベースのポリシー）で自分が引き受けてよいプリンシパルとして定義されている必要があります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
上記は「EC2サービスがこのロールを引き受けることを許可する」という信頼ポリシーです。
2. AssumeRoleの4つの代表的なシナリオ
シナリオ1：クロスアカウントアクセス
開発環境のアカウントから本番環境のアカウントのリソースに一時的にアクセスしたい場合に使います。
開発アカウントのIAMユーザー
→ 本番アカウントのロールをAssumeRole
→ 本番アカウントのS3バケットに一時的にアクセス
【メリット】
・本番アカウントにIAMユーザーを作る必要がない
・アクセスキーを本番環境に置かなくて済む
・一時的な認証情報なので漏洩しても自動で失効する
シナリオ2：EC2・LambdaなどのAWSサービスへの権限委任
EC2インスタンスで動くアプリケーションがS3やDynamoDBにアクセスする場合に使います。
EC2インスタンス
→ インスタンスプロファイル経由でIAMロールを引き受ける
→ S3・DynamoDBにアクセス
【メリット】
・アプリのコードにアクセスキーを埋め込まなくて済む
・一時的な認証情報が自動でローテーションされる
これが次のセクション「EC2へのロールアタッチ」の話です。
シナリオ3：外部フェデレーション（SAML・OIDC）
社内のIdP（ID プロバイダー）で認証した従業員がAWSにアクセスする場合に使います。
社内IdP（Active Directory等）で認証
→ AssumeRoleWithSAMLまたはAssumeRoleWithWebIdentityを呼び出す
→ IAMロールの一時的な認証情報を取得
→ AWSリソースにアクセス
【メリット】
・従業員ごとにIAMユーザーを作る必要がない
・既存の社内IDをそのまま使える
・人が会社を辞めたとき、IdP側だけ無効化すれば済む
シナリオ4：サードパーティへの一時的な委任
監査会社など外部のAWSアカウントに自社リソースへのアクセスを一時的に渡す場合に使います。
このシナリオでは ExternalId というパラメータを使って「混乱した代理人問題」を防ぐことが推奨されています。
【混乱した代理人問題とは】
監査会社Aが複数の顧客のロールを引き受けられる立場にある場合
悪意のある第三者が「監査会社Aを使って別の顧客のリソースにアクセスする」
ように仕向けることができてしまう問題
【ExternalIdを使った対策】
信頼ポリシーにExternalId条件を付けることで
監査会社Aが自社専用の値を持っている場合にのみAssumeRoleを許可する
→ 第三者が監査会社Aを騙って別の顧客のロールを引き受けることを防ぐ
3. AssumeRoleが満たすセキュリティのベストプラクティス
AWS公式のIAMセキュリティのベストプラクティスにおいて、AssumeRoleは以下の項目を直接満たします。
① ワークロードにIAMロールで一時的な認証情報を使用する
EC2・LambdaなどのAWSコンピューティングサービスで構築する場合、AWSがそのコンピューティングリソースにIAMロールの一時的な認証情報を配信します。そのため、AWSで実行されているワークロードにIAMユーザーの長期的な認証情報を配布する必要はありません。
② 人間のユーザーにはIDプロバイダーとのフェデレーションを使用する
AssumeRoleWithSAMLやAssumeRoleWithWebIdentityを経由することで、IAMユーザーを作らずに既存の社内IDを使ってAWSにアクセスできます。
③ 最小特権アクセス許可を適用する
ロールごとに必要な権限だけを定義し、必要なときだけAssumeRoleで引き受けることで、普段は余分な権限を持たずに済みます。
長期認証情報との本質的な違い
| 比較項目 | 長期認証情報（アクセスキー） | 一時的な認証情報（AssumeRole） |
|---|---|---|
| 有効期間 | 手動で削除するまで永続 | 数分〜数時間で自動失効 |
| 漏洩時のリスク | 手動でローテーションするまで有効 | 有効期限切れで自動無効化 |
| 管理コスト | 定期的なローテーションが必要 | ローテーション不要 |
| 埋め込みのリスク | コードに埋め込む誘惑がある | SDKが自動で取得・更新 |
4. EC2へのロールアタッチの正しい構造
「EC2に権限を付与したい」とき、実はEC2インスタンス自体にポリシーをアタッチすることはできません。正しい構造を理解しておきましょう。
EC2 → インスタンスプロファイル → IAMロールの関係
EC2インスタンス
└─ インスタンスプロファイル（コンテナ）
└─ IAMロール ← ここにポリシーをアタッチする
インスタンスプロファイルはIAMロールのコンテナです。EC2インスタンスに関連付けることで、そのインスタンス上のアプリケーションが一時的な認証情報を自動的に取得できるようになります。
コンソールで操作するときの注意点
IAMコンソールでEC2用のロールを作成すると、コンソールは自動的にインスタンスプロファイルも作成し、ロールと同じ名前を付けます。そのためコンソール操作では「ロールを作ってEC2にアタッチ」という直感的な手順で済みます。
ただし、AWS CLIやCloudFormationでロールを作成する場合はインスタンスプロファイルを別途作成する必要があります。
1インスタンスにつき1ロールの制約
インスタンスプロファイルに含めることができるIAMロールは1つだけです。この制限は緩和できません。1つのロールに複数のポリシーをアタッチすることで対応します。
5. 冒頭エピソードの回答：研修環境の権限設計
いよいよ冒頭のエピソードに戻ります。
状況の整理
・AWSアカウントを受講生1人ひとりに配布している
・受講生はIAMユーザーとしてログインして操作する
・IAMユーザーに何もポリシーがアタッチされていない
→ デフォルトは全拒否のため、EC2が作れない
この記事で学んだ知識を使うとどうすればよかったかを整理します。
5.1 誰に付与するか ― IAMグループを使う
受講生が複数人いるため、IAMグループを作ってグループにポリシーをアタッチします。
【グループを使わない場合（非推奨）】
受講生A → AmazonEC2FullAccess をアタッチ
受講生B → AmazonEC2FullAccess をアタッチ
受講生C → AmazonEC2FullAccess をアタッチ
↑ 受講生が増えるたびに同じ作業を繰り返す
【グループを使う場合（推奨）】
グループ「training-students」→ AmazonEC2FullAccess をアタッチ
受講生A・B・C → グループに追加するだけで完了
5.2 何を付与するか ― まずAWS管理ポリシーから始める
AWS公式のベストプラクティスでは「AWS管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する」とされています。研修環境はまさにこの考え方に沿っています。
研修で使うサービスに対応するAWS管理ポリシーをグループにアタッチします。
| 使うサービス | アタッチするAWS管理ポリシー |
|---|---|
| EC2 | AmazonEC2FullAccess |
| S3 | AmazonS3FullAccess |
| RDS | AmazonRDSFullAccess |
| CloudWatch | CloudWatchFullAccess |
5.3 渡したくない権限はカスタマー管理ポリシーのDenyで追加する
フルアクセスを与えたうえで、特定の操作だけ禁止します。Denyは常にAllowより優先するというルールを利用します。
なぜAllowを絞り込むのではなくDenyを追加するのか
「使えてほしい操作の数 >> 禁止したい操作の数」という研修環境では、許可一覧を全部書き出すよりフルアクセスを与えてDenyで例外を作るほうが管理が楽です。また禁止事項は研修内容が変わっても比較的安定しているため、独立したポリシーとして管理しやすくなります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyDangerousEC2Actions",
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances",
"ec2:DeleteVpc",
"ec2:DeleteSubnet"
],
"Resource": "*"
},
{
"Sid": "DenyS3BucketDelete",
"Effect": "Deny",
"Action": [
"s3:DeleteBucket"
],
"Resource": "*"
},
{
"Sid": "DenyIAMOperations",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:DeleteUser",
"iam:AttachUserPolicy",
"iam:PutUserPolicy",
"iam:CreateAccessKey"
],
"Resource": "*"
},
{
"Sid": "DenyBillingAccess",
"Effect": "Deny",
"Action": [
"billing:*",
"budgets:*",
"ce:*"
],
"Resource": "*"
}
]
}
このポリシーを TrainingRestrictions という名前でカスタマー管理ポリシーとして作成し、グループにアタッチします。
権限評価のイメージ
AmazonEC2FullAccess → ec2:TerminateInstances を Allow
↕
TrainingRestrictions → ec2:TerminateInstances を Deny
→ DenyがAllowに優先するため、インスタンスの削除は不可
5.4 最終的な構成
IAMグループ「training-students」
├─ AmazonEC2FullAccess （AWS管理ポリシー）
├─ AmazonS3FullAccess （AWS管理ポリシー）
├─ AmazonRDSFullAccess （AWS管理ポリシー）
└─ TrainingRestrictions （カスタマー管理ポリシー・Denyのみ）
受講生A → グループ「training-students」に追加
受講生B → グループ「training-students」に追加
5.5 事務局側の操作手順（IAMコンソール）
1. カスタマー管理ポリシー「TrainingRestrictions」を作成する
IAM → ポリシー → ポリシーを作成 → JSONに上記のDenyポリシーを貼る
2. IAMグループ「training-students」を作成する
IAM → ユーザーグループ → グループを作成
3. グループにポリシーをアタッチする
グループ → アクセス許可タブ → ポリシーをアタッチ
→ AmazonEC2FullAccess・AmazonS3FullAccess・TrainingRestrictions を選択
4. 受講生のIAMユーザーをグループに追加する
グループ → ユーザータブ → ユーザーを追加
受講生が増えたときはステップ4を繰り返すだけです。研修内容が変わって禁止したい操作が増えたときは TrainingRestrictions を編集するだけで全受講生に即時反映されます。
5.6 補足：さらに安心な環境にするならアクセス許可の境界
今回は使用しませんが、より厳密な研修環境を作りたい場合の選択肢として紹介します。
今回のDenyポリシーは「AllowされているものをDenyで上書きする」構成です。受講生がIAMの操作権限を持っていた場合（今回は TrainingRestrictions でIAM操作をDenyしているので基本的には問題ありませんが）、自分でポリシーを操作して権限を昇格しようとするリスクが理論的にはあります。
アクセス許可の境界を設定すると、IDベースのポリシーで付与できる権限の上限を構造的に固定できます。
アクセス許可の境界（例：ec2・s3・rds のみ上限として許可）
↕
IDベースのポリシーがどれだけAllowを書いても
→ 境界の外のサービスは有効にならない
→ 受講生が自分でポリシーをアタッチして権限昇格できない
ただしアクセス許可の境界はグループではなくIAMユーザー個別に設定する必要があります。受講生が多い場合は設定コストが上がるため、研修参加者のスキルレベルや操作されると困るリソースの重要度に応じて採用を検討してください。
6. セキュリティのベストプラクティスまとめ
AWS公式のIAMセキュリティのベストプラクティスをまとめます。
| ベストプラクティス | 内容 |
|---|---|
| 一時的な認証情報を使用する | 人間・ワークロードともにIAMロールと一時的な認証情報を使う |
| ルートユーザーの認証情報を保護する | 日常的なタスクにはルートユーザーを使わない |
| MFAを必須にする | IAMユーザーやルートユーザーにMFAデバイスを設定する |
| 最小特権を適用する | タスクの実行に必要なアクセス許可のみを付与する |
| AWS管理ポリシーから始める | まずAWS管理ポリシーを使い、徐々に最小特権に移行する |
| 未使用の認証情報・ポリシーを削除する | 定期的に見直して不要なものを削除する |
| IAM Access Analyzerを活用する | アクセスアクティビティに基づいて最小特権ポリシーを自動生成できる |
| アクセス許可のガードレールを確立する | 複数アカウントに拡大したらSCP・RCPで組織横断のガードレールを設ける |
おわりに
全4本にわたってAWSの権限管理を整理してきました。
最初のエピソードで「EC2が作れなかった」原因は「IAMユーザーにポリシーがアタッチされていなかった（デフォルト全拒否）」というシンプルなものでした。でも「どうすればよかったのか」を正確に答えるには、ポリシーの種類・グループの使い方・Denyの優先ルール・最小特権の考え方まで一通り理解する必要があります。
この連載がAWSの権限まわりの全体像をつかむきっかけになれば嬉しいです。