クロスアカウントアクセス設計

1. クロスアカウントアクセスは「どのアカウントのアイデンティティで操作するか」から考える

2つのAWSアカウントを考えます。

アカウント A
アプリケーション / 管理者
        │
        │
        ▼
アカウント B
AWS リソース

このとき最初に決めるのは、どのポリシーを書くかではありません。

アカウント Bのロールを引き受けて
アカウント B側のアイデンティティとして操作する？

        または

アカウント Aのアイデンティティのまま
アカウント Bのリソースへ直接アクセスする？

クロスアカウントアクセスの代表的な方式として、IAMロールを利用する方式と、対応サービスでリソースベースのポリシーによってリソースを直接共有する方式があります。

2. 送信元アカウントと対象アカウントを分ける

以降、次のように呼びます。

送信元アカウント
→ アクセスするプリンシパルが存在するアカウント

対象アカウント
→ アクセスさせたいロール / リソースが存在するアカウント

例えば、アカウント Aの開発者ロールからアカウント Bの本番リソースへアクセスするなら、アカウント Aが送信元、アカウント Bが対象です。クロスアカウント問題では、送信元側だけ・対象側だけを見ないことが重要です。

3. クロスアカウントアクセスには2つの基本方式がある

対象側のアイデンティティへ切り替えたい？
↓
IAMロール

特定リソースを直接共有したい？
+
そのサービスがリソースベースのポリシー対応？
↓
リソースベースのポリシー

すべてのAWSサービスがリソースベースのポリシーをサポートするわけではないため、直接共有できない場合はクロスアカウントロールが重要になります。

4. ロール方式は「ロールを引き受けるまで」と「引き受けた後」を分ける

クロスアカウントロールでは、次の2段階があります。

フェーズ 1
ロールを引き受けられるか？

送信元プリンシパル
↓
sts:AssumeRole
↓
対象ロール


フェーズ 2
ロールセッションで何ができるか？

対象ロールセッション
↓
ロール権限
↓
AWS リソース

ここを混ぜないことが重要です。

5. 送信元側ではsts:AssumeRoleを許可する

アカウント Aのプリンシパルがアカウント Bのロールを引き受ける場合、送信元側のアイデンティティベースのポリシーでは例えば次のように、誰がどのロールに対してsts:AssumeRoleを実行できるかを定義します。

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::222222222222:role/ProductionReadRole"
}

6. 対象側では信頼ポリシーが「誰を信頼するか」を決める

対象アカウントのIAMロールには信頼ポリシーがあります。信頼ポリシーは、誰がこのロールを引き受けてよいかを定義するロール固有のリソースベースのポリシーです。

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111111111111:root"
  },
  "Action": "sts:AssumeRole"
}

この例ではアカウント 111111111111へロール利用の信頼を委譲しています。

7. 送信元権限と信頼ポリシーは両方必要

送信元アカウント
アイデンティティベースのポリシー
↓
「このロールへAssumeRoleしてよい」

AND

対象アカウント
信頼ポリシー
↓
「このプリンシパルを信頼する」

送信元側だけ許可
+
対象が信頼しない
↓
AssumeRole失敗

対象が信頼
+
送信元側にAssumeRole 権限なし
↓
AssumeRole失敗

クロスアカウントロールでは送信元側の権限と対象側の信頼を両方確認します。

8. 信頼ポリシーとロール権限ポリシーは役割が違う

信頼ポリシーでアカウント Aを信頼していても、ロール権限がs3:GetObjectしか許可していないなら、ロールセッションがEC2インスタンスを終了できるわけではありません。

信頼
≠
リソース権限

9. クロスアカウントロールは3つの制御ポイントで読む

① 送信元アイデンティティベースのポリシー
   ↓
   sts:AssumeRoleを許可？

② 対象信頼ポリシー
   ↓
   送信元プリンシパルを信頼？

③ 対象ロール権限
   ↓
   ロールセッションが目的のアクションを許可？

どれかが成立していなければ、目的の操作はできません。

10. AWS STSとAssumeRole

条件が成立すると、送信元プリンシパルはAWS Security Token Service（AWS STS）のAssumeRoleを利用して対象ロールを引き受けます。

送信元プリンシパル
      │
      │ AssumeRole
      ▼
    AWS STS
      │
      ▼
一時的なセキュリティ認証情報
      │
      ▼
対象ロールセッション

AssumeRoleによって作成されたロールセッションでは、一時的なセキュリティ認証情報を利用します。ロールセッションが持つ基本権限は、引き受けたロールの権限ポリシーによって決まります。

11. 一時認証情報で対象アカウントを操作する

アカウント Aの元プリンシパル
↓
AssumeRole
↓
アカウント Bのロールセッション
↓
一時的な認証情報
↓
アカウント B リソース

クロスアカウントロールは、送信元アカウントの長期アクセスキーを対象アカウントへコピーする設計ではありません。ロールとSTSを利用することで、対象アカウント向けに新しい長期認証情報を配布せずに権限を委譲できます。

12. リソースを直接共有できる場合もある

一部のAWSサービスでは、リソースそのものへリソースベースのポリシーを設定できます。

アカウント A プリンシパル
        │
        │ S3 GetObject
        ▼
アカウント B S3 バケット
        │
        └─ バケットポリシー
           プリンシパル: アカウント A

この場合、アカウント Aのプリンシパルがアカウント Bのロールを必ず引き受ける必要はありません。

13. リソースベースのポリシーでは両アカウントの許可を見る

クロスアカウントでリソースを直接共有する場合、基本的には送信元側のアイデンティティベースのポリシーと対象側のリソースベースのポリシーを確認します。

送信元アカウント
アイデンティティベースのポリシー
↓
対象アクションを許可

AND

対象アカウント
リソースベースのポリシー
↓
送信元プリンシパルを許可

例えばアカウント Aのロールからアカウント BのS3 バケットを読むなら、送信元側で対象バケットへのs3:GetObjectを許可し、対象側のバケットポリシーでもそのプリンシパルを許可します。

14. ロール方式と直接共有方式の違い

対象アカウント側で
まとまった権限を使わせたい
↓
クロスアカウントロール

特定リソースだけを直接共有したい
+
リソースポリシー対応
↓
リソースベースのポリシー

15. Principal: arn:aws:iam::<account>:rootの意味

信頼ポリシーやリソースベースのポリシーでは、次の指定を見ることがあります。

"Principal": {
  "AWS": "arn:aws:iam::111111111111:root"
}

これはアカウント 111111111111のルートユーザーだけを許可する、という意味ではありません。そのAWSアカウントへ権限を委譲する指定です。そのアカウント側の管理者が、どのIAM アイデンティティへ実際の権限を与えるかを制御します。

16. サードパーティアカウントを信頼するとき

自社で管理していないSaaS 提供側などにロールを引き受けさせる場合があります。

顧客アカウント
↓
IAMロール

↑ AssumeRole

サードパーティ AWSアカウント

このようなケースでは、信頼ポリシーの条件として外部IDを利用する設計を評価します。外部IDは第三者アカウントからのロール利用を安全に制御するための追加条件として利用できます。

自社管理外の第三者へロールを委譲
↓
プリンシパルだけでなく
追加の信頼条件も評価

外部IDは認証情報そのものではなく、第三者へロール利用を許可する際に混乱した代理問題を防ぐため、信頼ポリシーの条件へ追加できる識別子です。

17. 明示的な拒否も最終結果へ影響する

クロスアカウントアクセスでも、送信元権限と対象信頼 / リソースポリシーに許可があるだけで必ず許可されるわけではありません。適用される明示的な拒否や組織レベルのガードレールなどがあれば、最終リクエストは拒否されることがあります。

明示的な拒否
>
許可

クロスアカウントリクエストでは送信元アカウントと対象アカウント双方の評価を確認します。

18. 要件から方式を選択する

19. 混同ポイント

• 信頼ポリシーだけ設定すればロールを使える：クロスアカウントでは送信元プリンシパルにもsts:AssumeRoleが必要です。
• 信頼ポリシー = ロールが実行できるAWS アクション：ロールセッションのアクションはロール権限ポリシーで決まります。
• リソースベースのポリシー = IAMロール必須：対応リソースなら送信元プリンシパルから直接クロスアカウントアクセスできます。
• リソースベースのポリシーだけ見ればよい：クロスアカウントでは送信元アカウント側の権限も確認します。
• :root プリンシパル = ルートユーザーだけ：アカウントプリンシパルとしての委譲です。
• AssumeRole = 長期認証情報発行：AWS STSによる一時的な認証情報です。

20. SAP-C02判断フロー

別アカウントへのアクセスが必要
        │
        ▼
対象側アイデンティティへ切り替える必要がある？
        │
   ┌────┴────┐
  はい      いいえ
   │          │
   ▼          ▼
IAMロールリソースを直接共有可能？
   │          │
   │      ┌───┴───┐
   │     はい      いいえ
   │      │        │
   │      ▼        ▼
   │   リソース   IAMロール
   │   ポリシー
   │
   ▼
送信元アイデンティティポリシー
sts:AssumeRole
   │
   +
   │
対象信頼ポリシー
プリンシパル
   │
   ▼
AWS STS AssumeRole
   │
   ▼
一時的な認証情報
   │
   ▼
ロール権限
   │
   ▼
対象リソース

21. まとめ

クロスアカウントアクセス
↓
2方式

① クロスアカウントIAMロール
送信元アイデンティティポリシー
→ sts:AssumeRole

対象信頼ポリシー
→ 誰を信頼？

AWS STS
→ AssumeRole

一時的な認証情報
→ ロールセッション

ロール権限ポリシー
→ 何を実行できる？


② リソースベースのポリシー
送信元アイデンティティポリシー
→ リソースアクション

対象リソースポリシー
→ 誰にリソースを共有？

↓
送信元プリンシパルのまま直接アクセス

最重要ポイント：「クロスアカウントだからロール」と決め打ちせず、対象側アイデンティティへ切り替えるのか、リソースを直接共有するのかを先に判断します。

22. 主要AWS公式資料

• クロスアカウントリソースアクセス
• ロールの信頼ポリシー
• ロールを引き受けるアクセス許可
• IAMロールによるクロスアカウント委任
• クロスアカウントのポリシー評価