[AWS]クロスアカウントアクセス方法（スイッチロール）



## 1. 概念・用語

- **IAMロール**  
    AWSリソースへの操作権限をポリシーで定義する一種のセキュリティプリンシパル。    
    - IAMユーザーとは異なり、ロール自体で直接サインインはできず、あらかじめIAMユーザーでログインした後、そのユーザーがロールを引き受け（Assume Role）ることで、ロールの権限を利用する。
    - ロールに切り替えている間は、元のユーザー権限は一時的に無効となり、ロールに付与された権限のみが有効になる。切り替え終了後は元のユーザー権限が復元される。
- **クロスアカウントアクセス**  
    異なるAWSアカウント間で、あるアカウントのリソースへのアクセス権を委譲する仕組み。
- **クロスアカウントIAMロール**  
    別のAWSアカウントのプリンシパル（IAMユーザーやロール）が、そのロールを引き受けることを許可する信頼ポリシーを持つIAMロールのこと。これにより、あるアカウントの特定の権限を別アカウントに委譲できる。
- **STSとAssumeRole**  
    AWS STS (Security Token Service) は一時的な認証情報を発行するサービスで、`AssumeRole` APIは指定したIAMロールを引き受け、一時的なアクセスキー、シークレットキー、セッショントークンなどの認証情報を取得するために利用する。
    - 例えば、AWSアカウントA上のソフトウェアが、クロスアカウントでAWSアカウントB上のロールを`AssumeRole`すると、STSはそのロールの権限で利用できる一時認証情報を発行する。
    - この仕組みでは、ロール側に設定する信頼ポリシーで、どのプリンシパルに`sts:AssumeRole`を許可するか（必要に応じ外部IDやMFA要件などの条件を設定する）を定義し、ユーザー側はIAMインラインまたは管理ポリシーで`sts:AssumeRole`の実行を許可される必要がある。

## 2. ユースケース
- **開発環境と本番環境の切り替え**
    - 開発用と本番用でAWSアカウントや権限を分離している場合、開発アカウントのIAMユーザーでログイン後、本番アカウントに用意したIAMロールに切り替えて作業できる。
    - 例えば、開発アカウントのIAMユーザーに本番アカウントの管理者ロールをAssumeRoleする権限を与えておけば、1つのユーザー資格情報でサインインし、必要なときに本番権限を利用できる。これにより、複数のアカウントの個別ユーザー作成や再ログインの手間を省ける。
    - コンソールのSwitch Role機能を使えば、ワンクリックで簡単に切り替えが可能。
- **マルチアカウント運用**
    - 組織内でAWSアカウントを用途別や部門別に分ける場合、中央の認証用アカウントに利用者のIAMユーザーを置き、必要な他アカウントのロールをAssumeRoleさせる運用が一般的。
    - また、外部パートナーに限定的アクセスを許可する場合も、自社アカウントにクロスアカウントロールを作成し、相手側にそのロールをAssumeRoleしてもらう方法が有効。これにより、複数アカウント環境でも認証情報やユーザー管理を集約し、必要な権限のみを委譲できる。

## 3. 設定方法

クロスアカウントでロールを利用するには、ロールを提供する側（信頼されるアカウント）とロールを使用する側（信頼するアカウント）の双方で設定が必要となる。

### AWSマネジメントコンソールを使用する方法

1. **ロールの作成（信頼される側）**  
    対象アカウント（例：AccountB）でIAMロールを作成する。
    - ロール作成時、信頼ポリシーとして、ロールを引き受け可能なプリンシパル（例：AccountAのユーザーや特定のIAMユーザー/ロールARN）を指定する。
    - さらに、そのロールに付与する権限ポリシー（例：S3アクセス権限など）をアタッチする。
    - 例：AccountBにRoleXを作成し、AccountAのユーザーがAssumeRoleできるよう信頼ポリシーにAccountAを指定し、RoleXに必要なS3アクセス権限を付与する。
2. **ユーザー側ポリシー設定（信頼する側）**  
    AccountAのIAMユーザーに、対象ロールをAssumeRoleする権限を付与する。
    - 具体的には、そのユーザーに対し、`"Action": "sts:AssumeRole"`かつ対象ロールのARN（例：`arn:aws:iam::AccountB:role/RoleX`）へのAllowポリシーを付与する。
    - これにより、該当ユーザーはAWS STSのAssumeRole APIを実行できる（クロスアカウントアクセスでは、ロール側の信頼ポリシーとユーザー側のアイデンティティポリシーの両方がAllowである必要がある）。
3. **コンソールでSwitch Role**  
    AccountAのIAMユーザーでAWSにサインイン後、次の手順でロールを切り替える。
    - 画面右上のユーザー名をクリックし、「ロールの切り替え」を選択する。
    - 表示される画面で、ロール提供側のAWSアカウントID（またはエイリアス）とIAMロール名（例：RoleX）を入力し、「スイッチロール」を実行する。
    - 以降、ナビゲーションバー上に設定した表示名や色が反映され、ロールの権限で操作できる。
    - 元のユーザーに戻る場合は、同様に右上の表示名をクリックして「元のユーザーに戻る」を選択する。


## 4. 仕組み


```mermaid
sequenceDiagram
    participant User as IAMユーザー (Account A)
    participant IAM_A as Account A<br/>IAMポリシー
    participant STS as AWS STS
    participant IAM_B as Account B<br/>信頼ポリシー
    participant Role as IAMロール (Account B)
    participant SVC as AWSリソース (Account B)

    User ->> STS: AssumeRole(Role ARN in Account B)
    STS ->> IAM_A: ユーザーのIAMポリシー確認 (sts:AssumeRole許可?)
    IAM_A -->> STS: 許可OK
    STS ->> IAM_B: ロールの信頼ポリシー確認 (Account Aのユーザーを信頼?)
    IAM_B -->> STS: 信頼OK
    STS -->> User: 一時認証情報発行
    User ->> SVC: 一時認証情報でリソース操作リクエスト
    SVC ->> Role: ロールに付与されたポリシー評価
    Role -->> SVC: アクセス許可（または拒否）
    SVC -->> User: 操作結果応答
```

- **ユーザー側ポリシーのチェック**  
    STSは、Account Aのユーザーに`sts:AssumeRole`が許可されているか確認する。
- **ロール側信頼ポリシーのチェック**  
    次に、対象ロールの信頼ポリシーで、Account Aのユーザー（またはそのプリンシパル）が許可されているか検証する。
- 両方のチェックが成功すれば、一時認証情報が発行され、ユーザーはその認証情報を使ってAccount BのAWSリソースにアクセスできる。

## 5. 利用にあたっての注意事項

### IAMポリシーの制約

- **最小権限の原則**  
    AssumeRoleの許可は、必要最小限のリソースARNに絞り、場合によってはMFAなどの条件を付けるのが望ましい。
- **ルートユーザーは対象外**  
    ルートユーザーではコンソールのロール切替機能は利用できないため、必ずIAMユーザーを利用する。
- **信頼ポリシーの設定**  
    信頼ポリシーでアカウント単位（例：`arn:aws:iam::ACCOUNT-ID:root`）で許可すると、そのアカウント内のすべてのプリンシパルがAssumeRole可能になるため、必要に応じ特定のユーザーやロールに絞る。また、外部アクセスの場合はExternalIDや条件付き設定を検討する。
- **ExternalIDの制限**  
    ExternalIDを必須とするロールは、AWSコンソールのSwitch Role機能では利用できず、API/CLI経由でのみAssumeRole可能である。
- **セッションの有効期限**  
    一時認証情報のデフォルト有効期限は1時間で、CLIでは`--duration-seconds`で延長可能だが、コンソールのロール切替も1時間が上限である。長時間作業する場合は注意が必要。また、ロールチェーンの場合、二段目のロールは最大1時間に制限される。
### セキュリティの考慮事項
- **MFAの導入**  
    ロールをAssumeRoleする際、MFAを必須に設定することで不正利用リスクを低減できる。
- **一時認証情報の管理**  
    発行された一時認証情報は自動で失効するが、その有効期間中は強力な権限を持つため、漏洩防止に十分注意する必要がある。
- **権限の分離**  
    ユーザー側とロール側の両方で、必要な権限のみを付与し、定期的にレビューすることが重要である。
- **モニタリング**  
    CloudTrailなどでAssumeRoleの利用状況を定期的に監視し、ログに記録されたロールセッション名などを活用して、誰がどのロールを利用したかを追跡できるようにする。

### プラクティス
- **ロールの命名と表示色**  
    コンソールで複数のロールを切り替える場合、用途に応じたわかりやすい名前と色分け（例：開発用は緑、本番用は赤）を設定すれば、誤操作防止に役立つ。
- **不要権限の除去**  
    運用開始後も、各IAMユーザーが本当に必要なロールのみをAssumeしているか定期的にレビューし、不要なAssumeRole権限は速やかに削除する。

## 6. 参考文献

1. [ユーザーから IAM ロールに切り替える (コンソール) - AWS Identity and Access Management](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-console.html#:~:text=AWS%20Management%20Console%20%E3%81%A7%E3%83%AD%E3%83%BC%E3%83%AB%E3%82%92%E5%88%87%E3%82%8A%E6%9B%BF%E3%81%88%E3%82%8B%E3%81%A8%E3%80%81%E3%82%B3%E3%83%B3%E3%82%BD%E3%83%BC%E3%83%AB%E3%81%AF%E5%B8%B8%E3%81%AB%E5%85%83%E3%81%AE%E8%AA%8D%E5%8F%AF%E6%83%85%E5%A0%B1%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6%E5%88%87%E3%82%8A%E6%9B%BF%E3%81%88%E3%82%92%E8%AA%8D%E5%8F%AF%E3%81%97%E3%81%BE%E3%81%99%E3%80%82)
2. [IAM でのクロスアカウントのリソースへのアクセス - AWS Identity and Access Management](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html#:~:text=%E4%BE%9B%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AB%E3%80%81%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%20IAM%20%E3%83%AD%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6%E8%A8%B1%E5%8F%AF%E7%AE%A1%E7%90%86%E3%82%92%E4%B8%80%E5%85%83%E5%8C%96%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82)
3. [Enable a New Feature in the AWS Management Console: Cross-Account Access | AWS Security Blog](https://blogs.aws.amazon.com/security/post/Tx2MUS2R3CMGG8H/Enable-a-New-Feature-in-the-AWS-Management-Console-Cross-Account-Access)