🔐

【AWS IAM（第11回）】：「クロスアカウントアクセスの設計」 〜別アカウントの門を叩く〜

に公開
AWS
IAM
tech

🌱 はじめに

「本番アカウントのS3にあるログを、分析用アカウントのプログラムから読み取りたい」

こうしたケースで、分析用アカウントにIAMユーザーのアクセスキーを直接発行して渡すのは、
2026年の運用では禁じ手です。なぜなら、アカウントを跨いで「鍵」を物理的に受け渡すと、管理が煩雑になり漏洩リスクが高まるからです。

正解は、第9回で学んだ 「 IAMロール（AssumeRole） 」 を活用すること。
アカウントを跨いでも、やることは「着ぐるみを借りる」だけです。

➊ クロスアカウントの基本概念：2つのアカウント

クロスアカウントアクセスを考えるときは、登場人物を整理しましょう。

信頼するアカウント（アカウントB）

リソース（S3やDBなど）を持っている側。操作される側。
「誰ならうちの門をくぐっていいよ」という 招待状（信頼ポリシー） を用意します。

信頼されるアカウント（アカウントA）

操作するユーザーやプログラムがいる側。
「あっちのアカウントの門を叩いていいよ」という 許可証（アイデンティティポリシー） を持たせます。

➋ 権限の「両面待ち」：2つの鍵が必要

1つ目のアカウント内での操作と決定的に違うのは、「 両方のアカウントで許可が必要 」という点です。

場所 必要な設定 内容
アカウントB (Resource) 信頼ポリシー Principal に「アカウントAのID」を指定し、変身を許可する。
アカウントA (User) アイデンティティポリシー Action に sts:AssumeRole、Resource に「アカウントBのロールARN」を指定する。

片方の設定を忘れるだけで、たちまち Access Denied の迷宮入りです。。。

➌ クロスアカウントアクセスの実行フロー

  1. アカウントAのユーザーが、STSに対して「アカウントBのロールになりたい」とリクエスト。
  2. STSが「アカウントAのユーザーに許可があるか」と「アカウントBのロールがアカウントAを信頼しているか」をチェック。
  3. 問題なければ、 アカウントBのリソースを操作できる「一時的な鍵」 を発行。
  4. ユーザーはその鍵を使って、アカウントBのリソースを操作する。

➍ 【実践】Terraformでの設定例

アカウントB（リソース側）で、アカウントAからのアクセスを受け入れる設定を書いてみましょう。

# アカウントBで作成するロール
resource "aws_iam_role" "cross_account_role" {
  name = "AccountB-Access-Role"

  # アカウントAからの「着ぐるみ利用」を許可する（招待状）
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          # アカウントAのIDを指定（または特定のユーザーARN）
          AWS = "arn:aws:iam::ACCOUNT_A_ID:root"
        }
      }
    ]
  })
}

🎯 まとめ

  • クロスアカウントアクセスは、「 一時的な鍵（ロール） 」を使うのが鉄則。
  • アカウントB（リソース側）には「 誰を信じるか（信頼ポリシー） 」を書く。
  • アカウントA（ユーザー側）には「 あっちへ行く許可（AssumeRoleの権限） 」を与える。
  • 両方のアカウントで許可が揃って初めて、境界線を越えることができる。

Discussion