導入
企業では「開発用アカウント」「本番用アカウント」のように複数のAWSアカウントを分けて使うのが一般的です。では、別アカウントのリソースにアクセスするにはどうすればよいでしょうか。
説明
IAMポリシーには2種類あります。
| 種類 | アタッチ先 | 例 |
|---|---|---|
| アイデンティティベースポリシー | ユーザー・グループ・ロール | 「このユーザーはS3を読める」 |
| リソースベースポリシー | リソース自体（S3バケット、KMSキーなど） | 「このバケットはアカウントXからの読み取りを許可する」 |
S3の バケットポリシー はリソースベースポリシーの代表例で、バケット側に「誰がアクセスできるか」を書けるため、別アカウントのユーザーやロールにもアクセスを許可できます。
クロスアカウントで一時的に権限を借りる標準的な方法が、レッスン8で学んだ AssumeRole です。
sequenceDiagram
participant U as "アカウントA のユーザー"
participant S as "STS"
participant R as "アカウントB の IAMロール"
U->>R: "AssumeRoleを要求（信頼関係で許可済み）"
R->>S: "一時的な認証情報を発行"
S-->>U: "一時的な認証情報"
U->>R: "その認証情報でアカウントBのリソースを操作"
この仕組みでは、アカウントB側のロールに「アカウントAを信頼する」という 信頼ポリシー（Trust Policy） をあらかじめ設定しておきます。これにより、アカウントBはアカウントAのユーザーにアクセスキーを渡すことなく、必要な権限だけを一時的に貸し出せます。
具体例
「開発アカウント」と「本番アカウント」を分けている会社で、開発アカウントのCI/CDが本番アカウントのS3へデプロイしたい、という典型シーンです。
まずい方法：本番アカウントでアクセスキーを発行し、それを開発アカウントのCIに渡す。→ 恒久的な本番の鍵が開発側に置かれ、漏れれば本番が危険。
正しい方法（クロスアカウントロール）：
- 本番アカウントに「S3デプロイ専用ロール」を作り、その信頼ポリシーに「開発アカウントを信頼する」と書く
- CIは実行時に、そのロールを AssumeRole して一時認証情報を取得
- その一時認証情報で本番S3へデプロイ
これなら本番の恒久キーは一切共有されず、貸し出す権限も「S3デプロイだけ」に絞れ、一時認証情報は自動失効します。もし共有したいのがS3バケット1つだけなら、バケット側のバケットポリシーで開発アカウントに直接許可する手もあります。「恒久キーを共有せずに別アカウントへ」——答えはAssumeRoleかリソースベースポリシーです。
読んでみよう
「複数アカウントにまたがるが、恒久的なアクセスキーは共有したくない」という要件を見たら、「クロスアカウントロール＋AssumeRole」が定番の答えです。S3バケットだけの単純な共有であれば、バケットポリシーで直接許可する方法も選択肢に入ります。