クロスアカウント IAM ロール設計

クロスアカウント IAM ロールは、ある AWS アカウントのプリンシパルが別アカウントのロールを引き受ける 仕組みです。 マルチアカウント環境の権限委任の基盤となりますが、設計を誤ると深刻なセキュリティ事故に繋がります。 本記事ではクロスアカウントロールの設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

クロスアカウントロールの仕組み

クロスアカウントアクセスは STS (Security Token Service) の AssumeRole で実現します。

[アカウント A (信頼元)]
  ユーザー Alice
    │ (sts:AssumeRole)
    ▼
[アカウント B (信頼先)]
  ロール CrossAccountRole
    信頼ポリシー: アカウント A の Alice を信頼
    権限ポリシー: S3 読み取り等

信頼ポリシー (Trust Policy) の基本

信頼ポリシーは 誰がこのロールを AssumeRole できるか を定義します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_A:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

双方向の許可が必要

クロスアカウントアクセスには 両アカウントでの許可 が必要です。

側	必要な許可	設定場所
信頼元 (アカウント A)	sts:AssumeRole をユーザーに許可	IAM ポリシー
信頼先 (アカウント B)	アカウント A を信頼	ロールの信頼ポリシー

一時クレデンシャルの発行

AssumeRole が成功すると、一時クレデンシャル が発行されます。

• アクセスキー ID / シークレット / セッショントークン: 一時的
• 有効期限: 15 分〜 12 時間（最大）
• Long-lived クレデンシャル不要: アクセスキーの配布・管理が不要

SAP レベル：高度な設計シナリオ

Confused Deputy 問題

SAP で最も重要なセキュリティ論点が Confused Deputy (混同代理) 問題 です。

# 脆弱な構成
アカウント B のロール信頼ポリシー:
  Principal: { "AWS": "arn:aws:iam::ACCOUNT_A:root" }   ← アカウント A 全体を信頼

# 攻撃シナリオ
1. 悪意あるユーザーがアカウント A に IAM ロールを作成
2. そのロールからアカウント B のロールを AssumeRole
3. アカウント B のリソースに不正アクセス

Confused Deputy の防止 — aws:SourceArn / aws:SourceAccount

この問題を防ぐには、信頼ポリシーで 条件キーによる絞り込み を行います。

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::ACCOUNT_A:root"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "aws:SourceAccount": "ACCOUNT_A",
      "aws:SourceArn": "arn:aws:lambda:ap-northeast-1:ACCOUNT_A:function:MyFunction"
    }
  }
}

IAM ロールの信頼ポリシー設計パターン

SAP では用途に応じた信頼ポリシーの設計パターンを使い分けます。

パターン	Principal	条件キー	ユースケース
AWS サービスロール	lambda.amazonaws.com 等	aws:SourceArn	サービスへの権限委任
クロスアカウント (ユーザー)	別アカウントの ARN	aws:PrincipalTag	特定ユーザーのみ
クロスアカウント (サービス)	別アカウントの root	aws:SourceArn	Lambda 別アカウント等
外部 IdP	SAML / OIDC プロバイダ	SAML:aud, aws:RequestedRegion	フェデレーション

セッションポリシーによる権限の動的絞り込み

AssumeRole 時に セッションポリシー を渡すと、セッション中の権限を動的に絞り込めます。

ロールの権限: S3 の全バケット读写
  + セッションポリシー: 特定バケットのみ
= 実効権限: 特定バケットのみ

• 権限の AND: ロール権限 ∩ セッションポリシー = 実効権限
• 用途: 時限的・条件的な権限絞り込み
• 制約: 権限を 拡張はできない（絞り込みのみ）

External ID による第三者委任の保護

External ID は、第三者（SaaS ベンダ等）にアカウントへのアクセスを委任する際の保護機能です。

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::VENDOR_ACCOUNT:root"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "一意のランダム文字列"
    }
  }
}

ロールの権限ポリシー設計

信頼ポリシーだけでなく、権限ポリシーの最小化 も SAP の論点です。

• 最小権限の原則: 必要なアクション・リソースのみ許可
• 条件キーの活用: aws:RequestedRegion, aws:ResourceTag で動的制限
• ReadOnly ベース + 必要時のみ書き込み: 誤操作防止
• アクセスアドバイザーの活用: 未使用権限の特定と削除

クロスアカウントアクセスの監査

監査項目	ログ / ツール	設計論点
AssumeRole 実行履歴	CloudTrail (AssumeRole)	権限使用の追跡
信頼ポリシー変更	CloudTrail (IAM API)	設定変更の検知
未使用ロール	IAM Access Analyzer	不要ロールの削除
過剰権限	IAM Access Analyzer	権限の最小化推奨

制約とクォータ

項目	制約
ロールの最大セッション	12 時間
1 アカウントのロール数	1000（クォータ拡張可）
信頼ポリシーの Principal	アカウント / サービス / SAML / OIDC
セッションポリシー	絞り込みのみ（拡張不可）

まとめ

• SAA: クロスアカウントアクセスは信頼ポリシー + 権限ポリシーの双方向許可、 STS による一時クレデンシャル発行、という基本を理解する。
• SAP: Confused Deputy 問題と aws:SourceArn / aws:SourceAccount による防止、 External ID、セッションポリシー、権限の継続的最小化が求められる。

次は SCP と RCP で、組織レベルのガードレール設計を学びましょう。