クラウドセキュリティ

クロスアカウントアクセスくろすあかうんとあくせす

IAMロールAWS Organizations信頼ポリシーAssumeRoleマルチアカウント最小権限の原則

クロスアカウントアクセスについて教えて

簡単に言うとこんな感じ！

別々のAWSアカウント間で「ちょっとこのリソース使わせて」ができる仕組みだよ！会社Aの社員が、会社Bのビルに入館証を借りて入れるイメージ。鍵を共有しなくてもOKで、しかも「この部屋だけ」って制限もできるから安全なんだ！

クロスアカウントアクセスとは

クロスアカウントアクセスとは、異なるAWSアカウント（またはクラウドサービスの別アカウント）同士が、適切な権限設定のもとでリソースを共有・操作できる仕組みのことです。たとえば「開発アカウント」のシステムが「本番アカウント」のS3バケットにファイルを書き込む、といった構成がこれにあたります。

大企業や成長したスタートアップでは、セキュリティ・コスト管理・権限分離の観点からAWSアカウントを複数に分けて運用するのが一般的です。しかしアカウントが分かれると「必要なリソースにアクセスできない」という問題が生じます。クロスアカウントアクセスはこの問題を、パスワードや認証情報を共有せずに解決する手段として設計されています。

AWSではこの仕組みの中心に IAMロール（Identity and Access Management Role） を置いています。別アカウントのユーザーやサービスが一時的にそのロールを「引き受ける（AssumeRole）」ことで、必要最小限の権限だけを安全に委譲できます。

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

クロスアカウントアクセスは「信頼関係（Trust）」と「権限（Permission）」の2つを組み合わせて成立します。

要素	役割	設定する場所
信頼ポリシー（Trust Policy）	「誰がこのロールを使ってよいか」を定義	アクセスされる側のアカウント（ロールに付与）
権限ポリシー（Permission Policy）	「このロールで何ができるか」を定義	アクセスされる側のアカウント（ロールに付与）
AssumeRole権限	「そのロールを引き受ける許可」を持つ	アクセスする側のアカウント（ユーザー/ロールに付与）

アクセスの流れ（4ステップ）

【アカウントA：開発環境】          【アカウントB：本番環境】
  ┌─────────────┐                  ┌─────────────────────┐
  │ IAMユーザー  │─① AssumeRole──▶│ IAMロール（信頼ポリシー）│
  │ or ロール    │                  │  └ Aのユーザーを信頼   │
  └─────────────┘                  └────────┬────────────┘
         ▲                                   │
         │④ 一時的な認証情報を受け取り操作     │② 一時認証情報を発行
         │                                   ▼
         └──────────────────────── AWS STS（Security Token Service）
                                    ③ 一時的なアクセスキー等を返却

覚え方：「信頼の握手、権限の鍵」

信頼ポリシー ＝「あなたを信頼します」という握手（誰が来てよいか）
権限ポリシー ＝「この鍵で開けられる部屋はここだけ」という制限（何ができるか）

両方そろって初めてアクセスが成立する、と覚えましょう。

AWSにおける主な活用パターン

パターン	具体例
環境分離	開発アカウント → 本番アカウントのリソースをデプロイ時だけ操作
ログ集約	各事業部アカウント → セキュリティ監視アカウントへのCloudTrailログ送信
共有サービス	各アカウント → DNS・Active Directoryなどの共通インフラアカウントを参照
委託開発	ベンダーのAWSアカウント → 自社アカウントへの作業アクセス（期間限定）
CI/CD	GitHub Actions / CodePipeline が本番アカウントのECSにデプロイ

歴史と背景

2012年頃〜 AWSのIAMが整備され、アカウント間のロール委任が可能になる。当初は大企業のみが複数アカウントを使う構成を採用
2015年 AWS Organizations（複数アカウントを束ねる管理サービス）の前身となる概念が登場。マルチアカウント戦略が注目され始める
2016年 AWS Organizationsが正式リリース。アカウントをグループ（OU: Organizational Unit）で管理できるようになり、クロスアカウントアクセスの需要が急増
2019年 AWS Control Tower が GA（一般提供開始）。マルチアカウント環境のガバナンスが自動化され、クロスアカウントアクセスの設計がベストプラクティスとして広く普及
2020年代〜 セキュリティインシデントを受け「アカウント単位でのブラストラディウス（被害範囲）の限定」が強く推奨されるようになり、クロスアカウントアクセスは現代クラウド設計の標準的な要素となった

リスク	対策
広すぎる権限の付与	最小権限の原則：ロールのポリシーは必要最小限に絞る
ロールの野放し	ExternalId（外部IDの条件）を信頼ポリシーに追加し、成り済まし（Confused Deputy攻撃）を防ぐ
長期間の認証情報漏洩	AssumeRoleで発行される認証情報は一時的（デフォルト1時間）。長期アクセスキーを使わない
アクセスログ未取得	CloudTrailでAssumeRoleイベントを記録し、誰がいつロールを使ったか追跡する
意図しない公開アカウント	信頼ポリシーの `Principal` に `*`（全員）を指定しない

規格・RFC番号	内容
RFC 6749	OAuth 2.0 フレームワーク。クロスアカウントにおけるOIDC連携（GitHub ActionsなどによるWebIdentityTokenの利用）の基盤となる認可フロー
RFC 7519	JSON Web Token（JWT）。OIDC連携でAssumeRoleWithWebIdentityを使う際のトークン形式

クロスアカウントアクセスくろすあかうんとあくせす

クロスアカウントアクセスとは

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

アクセスの流れ（4ステップ）

覚え方：「信頼の握手、権限の鍵」

AWSにおける主な活用パターン

歴史と背景

関連する設計アプローチとの比較

クロスアカウントアクセスのセキュリティ注意点

関連する規格・RFC

関連用語