ゆめさくエンジニア研究所女性向けエンジニアスクール女性向けエンジニアスクール
ログイン

AssumeRole とロールの連鎖

レッスン 3-5

権限の設定の 1 行が、環境ぜんたいの境目を決めます。

目安 60 分 トラック 3 攻撃と検証の 5 本目

読み終えたら強すぎるロールの連鎖を自分の環境で再現し、絞れる

この頁の流れ

  1. 1なぜ通るのか
  2. 2脆い設定と直した設定
  3. 3ログでの見え方と検知
  4. 4直し方と確かめ方
  5. 5関わる事例
  6. 6確認クイズ
  7. 7説明課題
  8. 8一次資料
  9. 9次へ

AssumeRole は、AWS の IAM ロールを引き受けて、期限つきの鍵 (一時的な認証情報) を受け取る操作です。引き受けた鍵でさらに別のロールを引き受けることをロールの連鎖と呼び、信頼のポリシーの書き方 1 行で、入口から管理者まで道がつながります。AssumeRole と PassRole の違い、公開の置き場と強すぎる権限を含む 3 つの経路を、ポリシーと手元の小さな解析のコードで比べます。CloudTrail の記録での見え方と、絞ったことを試験で固める方法までを扱います。

出典を確かめた日 2026年10月27日

なぜ通るのか

AssumeRole は、AWS の STS (一時的な認証情報を出す仕組み) の操作で、ロールを引き受けると、アクセスキー ID、秘密のアクセスキー、セッションのトークンの 3 つからなる期限つきの鍵が返ります。鍵の期限は 15 分から、ロールに決めた上限 (1 時間から 12 時間) までの間で選べます。誰が引き受けてよいかは、ロールに付けた信頼のポリシーで決まります。信頼の範囲を広く書きすぎると、AssumeRole は攻め手の乗り継ぎの道具にもなります。

ある Web アプリが AWS の上で動いているとします。アプリのサーバーには、画像の置き場を読むためのロール (役割に結び付いた権限の束) が付いています。作った人は、あとで要るかもしれないと考えて、このロールに「どのロールにでも乗り移ってよい」という許可も付けました。別の担当は、夜の集計のロールに「同じアカウントの中なら誰でも入ってよい」と書きました。

どちらの設定も、1 行ずつ見れば小さな手抜きです。2 つが並ぶと、アプリのサーバーに入った攻め手は、集計のロールを経由して、そこから届く物すべてに届きます。クラウドでは、網の内と外よりも、この権限の設定が境目になります。

root ユーザーと IAM の 4 つの部品

AWS で権限を扱う仕組みを IAM (Identity and Access Management) と呼びます。最初からある root ユーザーと、IAM の 4 つの部品は次の通りです。

部品役目
root ユーザーアカウントを作ったときの、すべてを許された身元。日々の作業には使わず、多要素認証をかけてしまっておく
ユーザー人や仕組みに結び付いた長く使う身元。アクセスキーを持てる
グループユーザーをまとめ、同じ許可をまとめて付ける
ロール必要な時だけ引き受ける身元。期限つきの鍵が発行される
ポリシー誰が、何に、何をしてよいかを JSON で書いた許可の表

ロールには 2 種類のポリシーが付きます。1 つは、ロールが何をしてよいかを書いた権限のポリシー、もう 1 つは、誰がロールを引き受けてよいかを書いた信頼のポリシーです。AWS の手引きは、人には ID の仕組みとの連携で一時的な鍵を使わせ、アプリなどの仕事にもロールの一時的な鍵を使わせ、長く使うアクセスキーは要る所だけに残すよう勧めています。

攻め手がたどる 3 つの経路

経路何が起きるか
公開の置き場置き場 (S3 のバケットなど) が誰からでも読める設定になっている
ロールの連鎖引き受けたロールから、さらに別のロールを引き受けて乗り継ぐ
強すぎる権限1 つの鍵が、仕事に要る範囲を超えて読める、書ける、渡せる

ロールの連鎖は、AWS の仕様そのものです。ロール A を引き受けた身元が、その鍵でロール B を引き受けられます。連鎖で得た鍵の期限は最長 1 時間に縛られますが、1 時間あれば置き場の中身を写すには十分です。

もう 1 つ見落とされやすいのが iam:PassRole です。AssumeRole と名前が似ていますが、役目が違います。

操作誰が使うか何が起きるか
AssumeRole人やアプリ自分がロールを引き受け、期限つきの鍵を受け取る
PassRole人やアプリが、サービスの設定のときにロールを AWS のサービス (仮想サーバーや関数など) に渡し、そのサービスにロールで動いてもらう

自分より強いロールを渡せる人は、そのロールで動く仕組みを作ることで、自分の権限を超えられます。どちらも、許す相手と渡してよいロールを名指しして絞ります。

公開の置き場については、AWS は 2023年4月から、新しく作るバケットで公開を止める設定 (S3 Block Public Access) を既定で有効にしました。それでも、古いバケットや、あとから設定を外した置き場は残ります。

脆い設定と直した設定

自分の PC の中で、ポリシーの書き方と、その結果どこまで届くかを比べます。AWS には接続しません。Python に付いている物だけで動きます。

信頼のポリシーで、誰を信じるか

脆いコード 同じアカウントの誰でも引き受けられる

JSON

{
  "Effect": "Allow",
  "Principal": {
    "AWS":
      "arn:aws:iam::111122223333:root"
  },
  "Action": "sts:AssumeRole"
}
直したコード 引き受けてよいロールを名指しする

JSON

{
  "Effect": "Allow",
  "Principal": {
    "AWS":
      "arn:aws:iam::111122223333:role/app"
  },
  "Action": "sts:AssumeRole"
}

脆い方の root は、アカウントの最上位の利用者だけを指すのではありません。AWS の手引きによると、アカウントを書くと判断はそのアカウントに任され、アカウントの中で引き受けの許可を持つ身元なら誰でも入れます。直した方は、引き受けてよいロールを 1 つだけ名指しします。

どこまで届くかを数える

ロールごとに、引き受けてよい先 (assume) と、引き受けを許す相手 (trust) を表にします。* はどれでも、account はアカウントの誰でも、の意味です。

脆いコード 乗り移り先を絞らず、アカウントを信じる

Python

ROLES = {
  "web-app": {"assume": ["*"],
              "trust": ["ec2"]},
  "batch":   {"assume": ["*"],
              "trust": ["account"]},
  "admin":   {"assume": [],
              "trust": ["account"]},
}
直したコード 乗り移り先と信じる相手を名指しする

Python

ROLES = {
  "web-app": {"assume": ["batch"],
              "trust": ["ec2"]},
  "batch":   {"assume": [],
              "trust": ["web-app"]},
  "admin":   {"assume": [],
              "trust": ["sso-admins"]},
}

どちらの表にも、同じ数え方を当てます。

届くロールをすべて数える

Python

def can_assume(src, dst, roles):
    to = roles[src]["assume"]
    by = roles[dst]["trust"]
    go = "*" in to or dst in to
    ok = "account" in by or src in by
    return go and ok

def reachable(start, roles):
    seen, todo = {start}, [start]
    while todo:
        src = todo.pop()
        for dst in roles:
            if dst in seen:
                continue
            if can_assume(src, dst,
                          roles):
                seen.add(dst)
                todo.append(dst)
    return seen

脆い表では、reachable("web-app", ROLES) が web-app、batch、admin の 3 つを返します。アプリのサーバーを破られると、管理者のロールまで届くということです。直した表では web-app と batch の 2 つだけで、admin は人の管理者の入口からしか引き受けられません。本物の判定には、ほかにも条件や境界の設定が効きます。この表は、連鎖の考え方を確かめるための最小の形です。

権限のポリシーで、何をさせるか

脆いコード 置き場のすべてに何でもできる

JSON

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}
直したコード 1 つの置き場の読み取りだけ

JSON

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource":
    "arn:aws:s3:::example-images/*"
}

脆い方の鍵が漏れると、アカウントの中のすべての置き場を一覧にし、写し、消せます。直した方は、画像の置き場から読むことしかできません。AWS の手引きは、最小の権限から始め、実際の使われ方の記録をもとに IAM Access Analyzer でポリシーを作り、使われていない許可を定期的に外すよう勧めています。

ログでの見え方と検知

ロールを引き受けると、AWS の操作の記録 CloudTrail に AssumeRole の行が残ります。AWS の手引きにある例を短くすると、次のような形です。

CloudTrail の AssumeRole の記録 (手引きの例を短くした物)

JSON

{
  "eventSource": "sts.amazonaws.com",
  "eventName": "AssumeRole",
  "userIdentity": {
    "type": "IAMUser",
    "arn":
      "arn:aws:iam::777788889999:user/John"
  },
  "sourceIPAddress": "192.0.2.101",
  "requestParameters": {
    "roleArn":
      "arn:aws:iam::111122223333:role/EC2-dev",
    "roleSessionName": "John-EC2-dev"
  }
}

userIdentity が誰が引き受けたか、requestParameters.roleArn がどのロールに入ったかを表します。連鎖のときは、userIdentity の型が引き受け済みのロール (AssumedRole) になります。守る側は次を見張ります。

見る物なぜ効くか
引き受け済みのロールからの AssumeRole連鎖そのもの。設計で決めた乗り継ぎの組以外は疑う
置き場の公開の設定やポリシーの書き換え公開の置き場は、設定を変えた瞬間に生まれる
ふだん使わないロールからの一覧の取得置き場の一覧は、持ち出しの前の下見になりやすい
AccessDenied の急な増え方届く所を探して、許可の無い操作を次々に試している

記録を取るだけでは足りません。記録が届く先と、警報に誰が気づくかまでを決めておきます。

直し方と、直ったことの確かめ方

手元の PC で、上のロールの表と数え方を使って行います。AWS のアカウントで試すときは、本番と切り離した自分の練習用のアカウントだけを使い、他人の環境やアカウントには向けません。

  1. 作業用のフォルダに、脆いロールの表と reachable を置く
  2. reachable("web-app", ROLES) に admin が入ることを確かめる
  3. 表を直したものに置き換え、admin が消えることを確かめる
  4. 下の試験を足し、脆い表に戻すと試験が落ちることも確かめる
  5. 練習用のアカウントでは、同じ形のロールを作って AssumeRole を 2 回続け、CloudTrail に 2 行が残ることと、直したあとは 2 回目が AccessDenied になることを確かめる
  6. 終わったら、作業用のフォルダと、練習用のアカウントに作ったロールと鍵を消す
連鎖が戻らないよう固める試験

Python

def test_app_cannot_reach_admin():
    got = reachable("web-app", ROLES)
    assert "admin" not in got

def test_no_wildcard_assume():
    for r in ROLES.values():
        assert "*" not in r["assume"]

def test_no_account_wide_trust():
    for r in ROLES.values():
        assert "account" not in r["trust"]

1 つ目の試験は、アプリの入口から管理者に届かないことを固定します。残りの 2 つは、だれかが手早く直そうとして * やアカウント全体の信頼を書き戻したときに落ちます。

AWS の上では、同じ確かめを IAM Access Analyzer に任せられます。外部やほかのアカウントから届く置き場とロールを洗い出し、ポリシーの書き方の誤りも検査します。

関わる事例

キャピタル・ワンの事例では、米控訴裁判所の判決によると、侵入した人物は AWS に結び付いた公開の IP アドレスを大量に走査し、弱い所を見つけると鍵 (認証情報) を問い合わせて手元に保存しました。その鍵で利用者の環境に直接入り、鍵の権限が許す範囲で、置き場のデータを丸ごと写しました。鍵を得た組織は少なくとも 200、データを盗まれたのは少なくとも 30 で、キャピタル・ワンからは米国の 9,800 万人の個人情報が持ち出されました。米通貨監督庁 (OCC) は、クラウドへ移る前のリスクの評価と、移ったあとの網の統制、警報への対応が不十分だったと認定しています。

トヨタの事例は、攻撃ではなく設定の誤りです。個人情報保護委員会によると、委託先のクラウドの環境の設定の誤りで、約 230 万人分の車載機 ID や車両の位置情報などが、約 10 年にわたり外から閲覧できる状態でした。委員会は、設定の不備でアクセス制御が適切に行われていなかったこと、委託元が委託先のアクセス制御を監査していなかったことを問題に挙げています。再発防止策には、クラウドの設定を見張る仕組みを入れ、技術的に公開の設定ができないようにすることが入りました。

確認クイズ

1 問目

ロールの信頼のポリシーに "AWS": "arn:aws:iam::111122223333:root" と書いてあります。これは何を意味しますか。

答えだと思う選択肢を押すと、その場で正誤と理由が開きます。

2 問目

CloudTrail に、引き受け済みのロールが別のロールを引き受けた記録が並んでいました。まず何を確かめますか。

答えだと思う選択肢を押すと、その場で正誤と理由が開きます。

説明課題

次のことを、自分の言葉で 3 行にまとめてください。書けたら、このレッスンは修了です。

  • 強すぎるロールの連鎖が生まれる理由と、絞り方
模範解答を見る

ロールは、引き受けてよい先と、引き受けを許す相手の 2 つの設定で、ほかのロールにつながる。* やアカウント全体を信じる書き方が 1 つずつ重なると、入口のロールから管理者のロールまで道ができる。乗り継ぎの先と信じる相手を名指しし、入口から届くロールを数える試験で、その道が戻らないよう固める。

一次資料

どれも 2026年10月27日に開いて、題と中身を確かめました。

次へ

次のレッスンは「報告と範囲」です (準備中)。見つけた経路を、決める人に届く報告にまとめる方法と、深刻度の数字の読み方を扱います。

セキュリティを仕事にしたいなら、国家試験の 情報処理安全確保支援士試験 の頁で、難易度、勉強時間と勉強法、資格を仕事につなげる道を見られます。

次のレッスン 3-6 報告と範囲 準備中

このレッスンにつながる物

トラック 3 攻撃と検証の中で

前のレッスン 3-4 横への広がりと認証情報

学んだことを次につなげる

ゆめさくセキュリティは、攻撃の仕組みを知り、自分の PC の中で壊して直し、守る側の判断を身につけるための学びの場です。

ラボはすべて自分の PC の中 (127.0.0.1) で閉じます。自分が管理していない相手に試すことは扱いません。