[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. 仕組み

• ユーザー側ポリシーのチェック
  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
2. IAM でのクロスアカウントのリソースへのアクセス - AWS Identity and Access Management
3. Enable a New Feature in the AWS Management Console: Cross-Account Access | AWS Security Blog