ロール引受けとS3の別判定

開発者Dev-41は別アカウントの帳票ファイルを読む必要があります。『ロールを作った』『一時認証情報を渡した』だけで、適切な対象だけにアクセスできるでしょうか。AWS IAMを具体例として、ユーザー、ロール、信頼ポリシー、権限ポリシー、リソースポリシー、最小権限、一時認証情報の発行・悪用・失効を一連のAPI呼出しで追います。製品固有の名称は他クラウドの機能へ読み替えてください。

読む順序は、用語→実際の構成と処理→記録の照合→異常の成立条件→変更・復旧→短答演習です。以下の組織、アドレス、時刻、識別子、ログは教材用の架空例です。観測できた事実と、追加調査が必要な推論を分けて読みます。

1. 用語をこの事案の判断に結び付ける

用語	意味とこの事案での判断の限界
IAM	Identity and Access Management。誰が、どの条件で、何に、どの操作をできるかを管理する仕組み。認証、ロールへの入り口、リソース操作の許可を分ける。
IAMユーザー	AWSアカウント内の長期的なIAM主体。人は組織のフェデレーション等を使う設計もある。この例のDev-41は説明用の主体で、恒久アクセスキーの配布を前提としない。
IAMロール	信頼された主体が引き受けて一時的に使う権限セット。ロール自体は通常のパスワードや恒久アクセスキーを持たない。
信頼ポリシー	誰がReportsReadRoleを引き受けられるかを定めるロール側のリソースベースポリシー。`sts:AssumeRole`を許す主体・条件を狭くする。
権限ポリシー	ロールを引き受けた後、どのAPI操作をどのリソースへ許すかを定める。この例では特定prefixの`s3:GetObject`だけを許す。
リソースポリシー	S3バケット等のリソースに付けるポリシー。主体、操作、条件を評価し得る。明示的なDenyは許可より優先する。
一時認証情報	STSのAssumeRole等で得るアクセスキーID、秘密キー、セッショントークンの組と有効期限。長期キーより期限を短くできるが、期限内に漏れれば悪用され得る。
最小権限	必要な主体・操作・リソース・条件・時間だけを許す方針。`s3:`や全バケット``を与えない。実際に使った操作と将来必要な操作をレビューする。
権限の上限	Permissions Boundary、SCP、セッションポリシー等は許可の上限に関わる。詳細な評価は組織・アカウント設定に依存し、Allow一行だけでは実効権限を決められない。

2. 構成と判断する位置

開発用Account-AのDev-41は、帳票用Account-BのReportsReadRoleをSTSで引き受けます。Account-BのS3バケットcorp-reportsにあるexport/配下のファイルだけを読む必要があります。Account-Aからのロール引受け権限とAccount-Bの信頼ポリシーの双方を確認し、ロール側の権限ポリシーを`s3:GetObject`に限定します。

架空の攻撃では、Dev-41の作業端末から一時認証情報が漏れ、攻撃者が期限内に同じロールセッションでexport/2026-09.csvを読んだ疑いがあります。ロールを狭くしていても、許可対象の帳票は読める可能性があるため、漏えい時刻、セッション、API呼出し、残る有効期間を調べます。

ロール引受けとS3の別判定

STSが発行する一時認証情報とS3が評価する操作権限を分ける。

STSの発行時に信頼ポリシー等で『ロールを引き受けてよいか』を判定し、S3の要求時に『その操作とオブジェクトを許すか』を別に評価します。監査ログへの記録は設定に依存し、S3のオブジェクトレベルイベントは有効化・保持を確認する必要があります。

3. 正常時の処理と管理

Dev-41がAccount-Aで組織の認証・MFAを通り、必要な`sts:AssumeRole`権限を持つことを確認する。
STSがAccount-BのReportsReadRole信頼ポリシーを評価し、許可された主体・条件なら期限付きの認証情報を発行する。
Dev-41がロールセッションでS3の特定オブジェクトを要求し、ロール権限、リソースポリシー、明示的Deny、上限を評価する。
export/配下の`GetObject`だけを許可し、他prefix、`DeleteObject`、バケット一覧は必要がなければ許さない。
AssumeRoleとGetObjectの監査イベントをsession、時刻、リソースで結び、利用状況と不要な権限を定期的に見直す。

クロスアカウントのロール引受けでは、Account-Aの主体がロールを引き受ける許可と、Account-Bのロール側の信頼が必要です。引受けに成功してもS3のすべての操作ができるわけではありません。実効権限はロール、バケット、組織上限、明示的拒否等の組合せで決まります。

4. 設定・記録のフィールドを読む

項目	読み方と注意点
principal / source_account	Dev-41とAccount-Aのどの主体か。アカウント全体のrootを信頼対象にすると、そのアカウント内の広い主体へ可能性が広がる。
role_arn / trust	Account-BのReportsReadRoleと信頼する主体。引受け条件を明示し、想定外の委託先やワークロードを含めない。
action / resource	`s3:GetObject`と対象オブジェクトARNの組。`ListBucket`にはバケットARNが必要で、GetObjectとは別。
effect / condition	Allow/DenyとMFA等の条件。明示的Denyや満たさない条件があればAllowがあっても拒否される。
session_name / expiration	一時認証情報のセッション識別子と期限。同名のセッションを使い回さず、実際の呼出しへ結ぶ。
access_key_id / token	ログに短い識別子を残せても秘密キー・セッショントークンは記録しない。漏れた組は期限まで有効になり得る。
cloud_audit / data_event	STSの引受けとS3オブジェクト操作。必要な監査設定が有効か、保持先が攻撃者に変更されていないか確認。

次は架空の簡略ログです。AWS製品の実際のフィールド名やイベントの有無は監査設定で異なります。アカウント番号とバケット名は教材用です。

text

09:00 STS account=A principal=Dev-41
  action=AssumeRole target=ReportsReadRole
  session=R-41 result=success expires=10:00
09:15 S3 account=B session=R-41
  action=GetObject key=export/2026-09.csv
  source_ip=198.51.100.41 result=success
09:16 S3 account=B session=R-41
  action=DeleteObject key=export/2026-09.csv
  result=AccessDenied

R-41が09:15に許可範囲の帳票を読むAPIへ成功し、09:16の削除は拒否されています。S3が成功を返したことと、Dev-41本人が操作したことは別です。source_ipの場所、端末、IdP、STS発行元を照合します。GetObjectがデータを返した範囲や下流への保存は必要なログで調べます。

5. 異常が成立する条件と証拠

状態・攻撃	成立条件、証拠、対策の位置
一時認証情報漏えい	攻撃者がアクセスキーID、秘密キー、トークンをセットで得て期限内に使える場合、許可されたGetObjectを悪用できる。期限切れだけに頼らずセッションを失効する。
広い信頼ポリシー	Account-Aの全主体を信頼すると、別の主体がAssumeRole権限を得た際に入れる。対象ロールと条件を限定する。
広い権限ポリシー	`s3:`と`Resource:`なら削除や他バケットへ波及し得る。必要な操作・prefix・条件で絞る。
権限昇格	`iam:PassRole`やポリシー変更等を許すと別の高権限主体へ到達し得る。管理APIを帳票読取ロールへ入れない。
監査の空白	S3オブジェクトイベントを収集していなければ、STS発行は見えても実際のGetObjectを追えない。事前に必要な監査を設定する。
共有セッション名	全員が同じsession名を使うと操作主体を区別しにくい。発行元ID、端末、チケットを結び付ける。

期限付き認証情報は長期キーより扱いやすいですが、漏えいした時点から期限までの不正利用を自動で防ぐものではありません。権限を最小化し、異常を検知し、必要ならロールセッションの失効と認証元の調査を実施します。

6. 調査で結論を強くする順序

判定段階	必要な証拠と結論の上限
誰が引き受けたか	STSイベントの元principal、認証方式、端末、source_ip、role/sessionを確認。session名だけで人を特定しない。
引受けが許された理由	Account-AのAssumeRole許可、Account-Bのtrust、条件、組織上限を確認。片側だけの設定画面で結論しない。
何ができたか	ロール権限、バケットポリシー、明示的Deny、セッションポリシー、Permissions Boundary、SCPを評価。Allow一行で決めない。
何をしたか	S3のオブジェクトレベル監査を対象key、結果、時刻で検索。未収集なら未観測と明記する。
漏えい範囲	成功したGetObjectの対象と応答、クライアント側保存、他の経路を確認。AccessDeniedはその一操作の拒否であり全操作の拒否ではない。
失効したか	発行済みセッションの無効化、既存のリクエスト、再発行経路の停止を確認。ロールポリシー変更だけで全既存セッションが即時消えると仮定しない。

ロールには入口と出口があります。入口はReportsReadRoleの信頼ポリシーであり、Account-Aのどの主体がAssumeRoleできるかを決めます。出口は引受け後の許可操作で、`s3:GetObject`をexport/配下へ絞ります。入口を絞っても出口が広ければ被害が大きく、出口を絞っても入口が広ければ利用主体が増えます。

S3のオブジェクトARNは`arn:aws:s3:::corp-reports/export/*`のように表す一方、バケット一覧の`ListBucket`はバケット自体のARNを使います。`GetObject`を許可しただけでは一覧取得はできませんが、既知のキーを直接指定できれば読める場合があります。『一覧不可だから閲覧不可』とは答えません。

明示的なDenyはAllowより優先します。例えばバケット側で特定の経路以外をDenyすれば、ロール側にGetObjectのAllowがあってもその要求は拒否されます。ただしポリシー評価は同一/クロスアカウントや権限境界で細部が変わるため、実際の設定をシミュレーションと監査イベントで検証します。

Dev-41が一時認証情報をノートやCIログへ貼ると、期限内は別端末から再利用され得ます。秘密値をログに残さない、作業端末を保護する、必要な時間だけ発行する、利用後に失効する設計が必要です。ロールセッションの期限を短くしても、攻撃者が元のDev-41認証を盗めば再発行できます。

GetObject成功が一件見つかった場合、帳票のデータ分類と業務上の影響を確認します。S3オブジェクトの監査が未設定なら『アクセスなし』とは言えません。バケット全体のポリシー変更、別のロール、事前に作られた共有URLなど、同じデータへ届く別経路も調査します。

最小権限の見直しでは、運用中のAPI利用ログから必要な操作を洗い出し、検証環境で権限を縮小します。ログに出ていない月末ジョブや障害対応で必要な操作を見落とすと業務が止まるため、担当部署と例外手順を決め、期限付きで段階的に変更します。

7. 変更・障害・例外運用

運用場面	崩れやすい条件と確認
入社・異動・退職	利用者と所属、ロール引受け権限、MFA、発行済みセッションを見直す。退職時は長期キーだけでなく一時セッションも確認。
委託先の追加	信頼ポリシーをアカウント全体へ広げず、委託先の専用主体・条件・期限を定義する。契約終了時の失効を準備。
業務変更	新しいS3 prefixが必要になったら操作・リソース・条件をレビュー。`Resource:*`へ逃げない。
漏えい時	セッション失効と元主体の再発行停止、端末調査、監査ログ保全を並行する。影響したオブジェクトと期間を特定。
障害時の例外	緊急ロールはMFA、承認、短時間、操作記録、事後レビューを付け、常設の管理者権限にしない。

ポリシー変更は単に管理画面でAllowを削るだけでは終わりません。既存の一時認証情報、バケット側の許可、別ロール、SCP等を含む実効権限を再評価し、正規の帳票閲覧と拒否すべき削除・別prefix閲覧の両方を試します。

8. 封じ込めと復旧条件

一時認証情報漏えい時の対応

1. 保全：対応 STSとS3を保存／確認する証跡 sessionとkey
2. 失効：対応セッションを止める／確認する証跡拒否と再発行
3. 影響確認：対応読取対象を調査／確認する証跡 S3データイベント
4. 権限修正：対応 trustと許可を絞る／確認する証跡正規・拒否試験

発行元、セッション、データの三つを調べる。

セッションを止めても、Dev-41の元の認証が侵害されていれば新しいセッションを発行できます。発行元の端末・認証と、過去に読まれたデータの調査を並行します。

STSの発行、S3のオブジェクト操作、ロール・バケットポリシー変更、Dev-41の認証ログを保全する。
疑わしいR-41を失効し、Dev-41の元資格情報・端末を調査して再発行を止める。正規業務の代替ロールを準備する。
GetObject成功の対象keyと時刻、他のロール・共有URL経路を調べ、帳票データの影響範囲を評価する。
Account-AのAssumeRole許可、Account-Bのtrust、ロール権限、バケットポリシー、組織上限を見直し、必要な主体・操作・prefixへ狭める。
新しい短期セッションで正規のexport/閲覧を確認し、別prefixとDeleteObjectが拒否されることを試す。監視と責任者承認の下で再開する。

単に一時キーが10:00に期限切れとなっても、09:15の読取を取り消せません。元の認証が使えれば再発行も可能です。過去の影響調査と、発行元・信頼関係の修正を分けて完了します。

9. 科目B（午後）の解答手順

設問では『誰がロールを引き受けられるか』と『引き受け後に何ができるか』を分けます。STSの発行、S3の操作、監査の有無、発行元の再利用を時系列で追い、最小権限と漏えい対応を具体的なAction・Resource・Principalで書きます。

trustとpermissionを分ける。
一時認証情報の期限と漏えい時の悪用期間を分ける。
Allowと明示的Deny、組織上限を合わせて評価する。
GetObject成功と人の本人性を分ける。
失効後の再発行経路を閉じる。

10. 短答演習

演習1：ロール存在

条件：Account-BにReportsReadRoleを作成。

質問：Dev-41は引き受けられるか。

解答：未確定。Account-A側の許可とAccount-B側のtrustを確認する。

誤答の理由：ロールの存在を引受け許可と混同している。

演習2：STS成功

条件：Dev-41がR-41を取得。

質問：全S3バケットを読めるか。

解答：違う。ロール権限とバケット側の設定を評価する。

誤答の理由：認証情報発行と操作許可を同一視している。

演習3：GetObjectだけ

条件：export/*のGetObjectを許可。

質問：バケットを一覧できるか。

解答：通常は別のListBucket許可が必要。ただしキー既知なら直接読め得る。

誤答の理由：対象操作の違いを見ていない。

演習4：期限

条件：R-41は10:00に期限切れ。

質問：09:15の読取はなかったことになるか。

解答：ならない。期間内の操作を監査し影響を調べる。

誤答の理由：期限切れを過去の操作の取消しと考える。

演習5：AccessDenied

条件：DeleteObjectが拒否された。

質問：情報流出なしと言えるか。

解答：言えない。GetObjectは成功している。

誤答の理由：一操作の拒否を全操作へ広げている。

演習6：失効

条件：R-41を失効した。

質問：再侵入を防げるか。

解答：元のDev-41認証とtrustを調べ、再発行経路を閉じる。

誤答の理由：一つのセッションだけを原因とみなしている。

11. 一次資料

AWS：IAMロールと一時認証情報

AWS：IAMポリシーと権限評価

AWS：一時認証情報の権限失効

クラウドIAM・ユーザー・ロール・ポリシーと最小権限