🔐 IAM PassRole vs AssumeRole

レストランの「代理店長制度」でたとえると超わかりやすい！完全ガイド

🍽️ レストランの代理店長で理解する2つの権限

IAMロールは「役職」のようなもの

PassRoleとAssumeRoleは、よく混同されがちですが、実は全く違う概念です。

PassRole ：「この役職を使っていいよ」と許可を与える権限
AssumeRole ：実際にその役職になりきって仕事をする行為

レストランの「代理店長制度」にたとえると一瞬で理解できます✨

📖 「Assume」ってどういう意味？

「AssumeRole」という名前の意味を理解すると、
概念がさらにクリアになります！

🔤 英単語「assume」の3つの意味
1

引き受ける・担う・就く

← IAMで使われているのはコレ！

📝 assume responsibility
（責任を引き受ける）

📝 assume the role
（役割を担う）

📝 assume office
（職務に就く）
2

仮定する・推測する

📝 assume that...
（〜と仮定する）

📝 Let's assume it's true
（それが真実だと仮定しよう）

⚠️ この意味ではありません
3

装う・ふりをする

📝 assume a false identity
（偽の身分を装う）

📝 assume an air of innocence
（無邪気なふりをする）

⚠️ この意味でもありません
🎭 レストランでの「assume」
マネージャー： 「田中さん、今日は代理店長をお願いします」
田中さん： 「わかりました！代理店長の役割を 引き受けます 」

↑ これが「assume the role」

田中さんが：
• 代理店長という 役割を引き受ける = assume the role
• 代理店長として 職務に就く = assume the position
• 店長の 責任を担う = assume the responsibility
🔐 なぜ「AssumeRole」という名前なのか？
AWSは「 あなたが一時的にそのロール（役割）になりきる 」という行為を表現するために、この英語の「assume」を使いました。

英語 直訳 意訳
AssumeRole 役割を引き受ける ロールになる
Assume a role ある役割を担う その立場に就く
🎬 俳優の演技でイメージすると
俳優が舞台で役を演じるようなイメージです：

俳優（IAMユーザー）
↓ assume the role of Hamlet
ハムレット（役柄=ロール）として演技

この間、俳優は「ハムレット」として行動し、
自分自身の普段の性格は表に出さない
同様に：

IAMユーザー
↓ AssumeRole
ロールの権限で行動

この間、元のユーザー権限は使えず、
ロールの権限のみが有効
💡 他の類似表現との比較
assumeと同じような意味で使われる英語表現：

take on a role
役割を引き受ける
step into a role
役割に入り込む
adopt a role
役割を採用する
でも、AWSは「assume」を選びました。理由は：

✅ 一時的な性質を表現できる
✅ ビジネス・法律用語として正式
✅ 「責任を伴う引き受け」のニュアンス
「assume」は単に役を「演じる」のではなく、その役職の 責任と権限を正式に引き受ける という重みのある言葉なんです！

つまり、AssumeRole =
そのロールの立場に就いて、
その権限と責任を引き受ける
📋
iam:PassRole
「許可を出す」権限
🎯 何をする権限？
他のAWSサービスに「このIAMロールを使っていいよ」と許可を出す権限。ロール自体を使うわけではなく、使う許可を与えるだけ。
🍽️ レストランでたとえると
マネージャーがスタッフに言う：
「田中さん、今日は店長が休みだから、代理店長として働いていいよ」

→ これが PassRole （許可を出す行為）
💼 実際のAWSでの使用例
• Lambda関数にIAMロールを渡す
• EC2インスタンスにIAMロールを割り当てる
• CodePipelineにデプロイ用のロールを渡す
• ECSタスクにロールを指定する
🔍 誰が持つ権限？
リソースを作成・設定する人 が持つ権限。
例：開発者、管理者、デプロイツール
⚠️ 重要なポイント
PassRoleを持っていても、 そのロール自体の権限は使えない 。あくまで「誰かに使わせる許可」を出せるだけ。
👤
sts:AssumeRole
「役割を引き受ける」行為
🎯 何をする行為？
実際にIAMロールになりきって、そのロールの権限を使って作業をする行為。一時的な認証情報を取得して、ロールの権限で行動する。
🍽️ レストランでたとえると
田中さんが実際に行動する：
「わかりました！それでは代理店長として店を運営します」
（実際に店長の権限で売上管理、スタッフ指示などを実行）

→ これが AssumeRole （役割を引き受ける行為）
💼 実際のAWSでの使用例
• 開発者が本番環境のロールにスイッチ
• Lambda関数が実行時にロールを引き受ける
• クロスアカウントアクセスでロール切替
• CI/CDツールがデプロイ用ロールを使用
🔍 誰が行う行為？
実際に作業を実行するエンティティ が行う。
例：IAMユーザー、AWSサービス（Lambda、EC2など）
⚠️ 重要なポイント
AssumeRoleすると、 元の権限は一時的に失われ 、ロールの権限のみが使える状態になる。一時的な認証情報（1時間など）が発行される。

🍽️ レストラン代理店長制度の完全シナリオ

📋

PassRole
「許可を出す側」

🎬 シーン1：マネージャーの権限
マネージャー（管理者）は「誰が代理店長になれるか」を決める権限を持っています。
📝 何を決められる？
• 田中さんを代理店長に任命できる
• 鈴木さんも代理店長に任命できる
• でも山田さんは任命できない（スキル不足）
⚠️ 重要な制限
マネージャー自身は代理店長ではないので、代理店長の仕事（売上管理、スタッフ評価など）は できません 。

許可を出すことと、実際にやることは別物！
🔐 セキュリティの観点
マネージャーは「誰に強力な権限を渡すか」を慎重に判断する必要があります。間違った人に渡すと大変なことに！
👤

AssumeRole
「役割を引き受ける側」

🎬 シーン2：田中さんの実行
田中さんは許可をもらったので、実際に代理店長として働きます。
💼 何ができるようになる？
• 売上レポートの確認
• スタッフへの指示
• 仕入れの承認
• クレーム対応の最終判断
⚠️ 重要な制限
代理店長として働いている間、田中さんは 普通のスタッフとしての仕事はできません 。

接客や料理など、通常の業務は一時的にできない状態に。
⏰ 時間制限
代理店長の権限は「今日の営業時間中だけ」など、期限付き。翌日はまた許可が必要。

→ AWSでは通常1〜12時間の一時的な認証情報

🔄 実際の動作フロー

📋 PassRole のフロー（許可を出す）
👨‍💼
開発者
Lambda関数を作成したい
→
📋
PassRole権限
開発者が持っている
「iam:PassRole」
→
🎯
ロールを指定
「LambdaExecutionRole」
をLambdaに渡す
→
✅
作成成功
Lambda関数が
ロール付きで作成される
👤 AssumeRole のフロー（役割を引き受ける）
⚡
Lambda起動
関数が実行される
→
👤
AssumeRole実行
Lambdaが自動的に
ロールを引き受ける
→
🎫
一時認証情報
有効期限付きの
アクセスキー取得
→
💼
作業実行
ロールの権限で
S3やDynamoDBにアクセス

💻 実際のIAMポリシー例

📋 PassRole ポリシー例 
// 開発者に付与するポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": 
        "arn:aws:iam::123456789012:role/LambdaExecutionRole",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": 
            "lambda.amazonaws.com"
        }
      }
    }
  ]
}

// 解説：
// この開発者は「LambdaExecutionRole」を
// Lambda関数に渡すことができる
// でも、そのロール自体は使えない！
👤 AssumeRole ポリシー例 
// ロールの信頼ポリシー（Trust Policy）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

// 解説：
// このロールは「Lambda関数」が
// AssumeRole（引き受ける）ことができる
// Lambda起動時に自動的に実行される

// ロールに付与する権限ポリシー
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "dynamodb:PutItem"
  ],
  "Resource": "*"
}

📊 詳細比較表

項目 iam:PassRole sts:AssumeRole
基本的な意味 「ロールを渡す許可」 「ロールになる行為」
実行するのは？ リソースを作成する人・サービス 実際に作業する人・サービス
どこに書く？ ユーザー/サービスのポリシー ロールの信頼ポリシー
いつ使う？ リソース作成・更新時 リソース実行時
権限の使用 ロールの権限は使えない ロールの権限を使える
一時的？ 永続的な許可 一時的（1-12時間）
認証情報 発行されない 一時認証情報が発行される
典型的な用途 Lambda/EC2作成時にロール割当 Lambda実行時、クロスアカウントアクセス

⚠️ よくある誤解トップ5

❌
誤解1：「PassRoleがあればそのロールを使える」
✅ 正しい理解：
PassRoleは「他の人・サービスに渡す許可」であって、自分がそのロールを使えるわけではありません。

例： マネージャーが「田中さんを代理店長にしていいよ」と言えても、マネージャー自身が代理店長になれるわけではない。
❌
誤解2：「AssumeRoleは管理者だけが使うもの」
✅ 正しい理解：
AssumeRoleは、Lambda、EC2、ECSなどのAWSサービスが自動的に実行します。人間だけでなく、サービスも常に使っています。

例： Lambda関数は起動のたびに自動的にAssumeRoleを実行して、権限を取得しています。
❌
誤解3：「PassRoleがないとLambdaが動かない」
✅ 正しい理解：
PassRoleが必要なのは「Lambda関数を作成・更新する時」だけ。既にロールが割り当てられているLambdaの実行には不要。

例： 既に代理店長が決まっていれば、毎日許可を出し直す必要はない。
❌
誤解4：「どんなロールでもPassRoleできる」
✅ 正しい理解：
PassRoleはロールごとに許可が必要。すべてのロールを渡せるわけではありません。

例： マネージャーは「代理店長」に任命する権限はあっても、「会社の社長」に任命する権限はない。
❌
誤解5：「AssumeRoleしても元の権限も使える」
✅ 正しい理解：
AssumeRoleすると、元の権限は一時的に使えなくなります。ロールの権限だけが有効になります。

例： 田中さんが代理店長になったら、普通のスタッフとしての接客業務はできない。店長としての権限のみ。

💼 実際のユースケース別ガイド

⚡

Lambda関数の作成

シナリオ：
開発者がS3からデータを読み込むLambda関数を作成したい。

必要な権限：
1️⃣ 開発者に
• lambda:CreateFunction（Lambda作成権限）
• iam:PassRole（ロールを渡す権限）

2️⃣ Lambdaロールの信頼ポリシーに
• sts:AssumeRole（Lambda用）

3️⃣ Lambdaロールの権限ポリシーに
• s3:GetObject（実際にS3にアクセス）
動作の流れ：
1. 開発者がPassRoleでロールを指定してLambda作成
2. Lambda起動時にAssumeRoleでロール引き受け
3. S3にアクセス
🔄

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

シナリオ：
開発アカウントから本番アカウントのリソースにアクセスしたい。

必要な権限：
1️⃣ 開発者（開発アカウント）に
• sts:AssumeRole（本番ロールを引き受ける）

2️⃣ 本番ロール（本番アカウント）の信頼ポリシーに
• 開発アカウントからのAssumeRoleを許可

3️⃣ 本番ロールの権限ポリシーに
• 必要なリソースへのアクセス権限
動作の流れ：
1. 開発者がAssumeRoleで本番ロールに切替
2. 一時認証情報取得
3. 本番環境のリソースにアクセス
🚀

EC2インスタンスプロファイル

シナリオ：
EC2インスタンスからS3バケットにアクセスさせたい。

必要な権限：
1️⃣ 管理者に
• ec2:RunInstances（EC2起動権限）
• iam:PassRole（ロールを渡す権限）

2️⃣ EC2ロールの信頼ポリシーに
• sts:AssumeRole（EC2用）

3️⃣ EC2ロールの権限ポリシーに
• s3:PutObject（S3への書き込み）
動作の流れ：
1. 管理者がPassRoleでロールを指定してEC2起動
2. EC2が自動的にAssumeRoleでロール引き受け
3. アプリケーションがS3にアクセス
🔧

CodePipelineでのデプロイ

シナリオ：
CI/CDパイプラインで自動デプロイを実行したい。

必要な権限：
1️⃣ 開発者に
• codepipeline:CreatePipeline
• iam:PassRole（パイプラインにロール渡す）

2️⃣ パイプラインロールの信頼ポリシーに
• sts:AssumeRole（CodePipeline用）

3️⃣ パイプラインロールの権限ポリシーに
• codebuild:StartBuild
• cloudformation:CreateStack
動作の流れ：
1. 開発者がPassRoleでパイプライン作成
2. パイプライン実行時にAssumeRole
3. デプロイ処理を実行
💡 ベストプラクティス＆セキュリティのコツ
1. PassRoleには必ず条件を付ける：
「iam:PassedToService」条件を使って、特定のサービスにのみロールを渡せるように制限しましょう。
例：Lambda専用ロールはLambdaにしか渡せないようにする。

2. 最小権限の原則を守る：
• PassRoleは必要なロールだけに限定
• ロールの権限も必要最小限に
• ワイルドカード（*）の使用は避ける

3. 信頼ポリシーを適切に設定：
AssumeRoleを許可する対象を明確に指定。誰でも引き受けられるロールは作らない。

4. ロールの命名規則を統一：
• サービス名-環境-用途の形式がおすすめ
• 例：Lambda-Prod-S3Access、EC2-Dev-DynamoDBWrite

5. CloudTrailでログを監視：
PassRoleとAssumeRoleは両方ともCloudTrailに記録されます。定期的に監査して、不正な使用がないか確認。

6. 外部IDを使用する（サードパーティアクセス時）：
クロスアカウントでサードパーティサービスを使う場合は、外部ID（ExternalId）を必ず設定して、混乱した代理人問題を防ぐ。

7. ロールのセッション時間を適切に設定：
長時間のセッションは避け、必要最小限の時間（デフォルト1時間）で設定。

8. タグ付けで管理を簡単に：
ロールにタグを付けて、用途や所有者を明確に。コスト配分や監査にも役立ちます。

🎓 まとめ

🍽️ レストランの代理店長制度 = IAMロール

PassRoleとAssumeRoleは全く違う概念！
許可を出すこと と 実際にやること は別物です

📋
PassRole

「この役職を使っていいよ」
と許可を出す権限

作成・設定時に必要
👤
AssumeRole

実際にその役職になりきって
仕事をする行為

実行時に必要

🎯 覚えておくべき4つのポイント：

1️⃣ PassRoleは「許可」、AssumeRoleは「実行」
マネージャーが許可を出して、スタッフが実際に働く

2️⃣ PassRoleを持っていても、そのロールは使えない
許可を出せるだけで、自分が代理店長になれるわけじゃない

3️⃣ AssumeRoleは一時的
代理店長の権限は期限付き。元の権限は一時的に使えない

4️⃣ 「Assume」=「引き受ける」という意味
AssumeRoleは「役割を引き受ける」行為。責任と権限を正式に担うこと

「assume」=「引き受ける」 という英語の意味を知れば、
AssumeRoleの概念がより深く理解できます！

この2つの違いを理解することで、
IAMロールのセキュリティ設計が劇的に向上 します！
レストランのたとえを思い出して、適切に使い分けましょう🎉

Created by SSuzuki1063

AWS SAP Learning Resources