クロスアカウントアクセスのシナリオ判断

監査会社への委譲と開発・本番アカウント間のアクセスを題材に、片側だけの設定不足を見つけます。

この単元で学ぶこと

  • 引受け拒否と実操作拒否を診断する
  • 第三者委譲の条件を点検する
  • 監査と委譲終了を設計する

本文解説

1. 相手は信頼している Bの信頼ポリシーへAを追加したがAからAssumeRoleが拒否された場合、A側の対象ロールへの許可を確認します。相手が信頼すると言っていることと、Aの利用者にその委譲利用が許されていることは別です。

2. 引受けはできた 監査ロールの引受けに成功しても、監査資料へのGetObjectが拒否されることがあります。ロールの権限、バケット側、暗号鍵側など実操作の条件を調べます。信頼先を全アカウントへ広げても、資料を読む許可不足の解決にはなりません。

3. アカウントを限定する 信頼先のアカウントroot ARNを見て、rootユーザー本人しか入れないと判断してはいけません。指定アカウントからの委任の意味を確認し、必要なら特定のロール等へ主体を絞ります。アカウント番号の入力ミスも確認します。

4. 複数顧客の監査会社 監査会社が顧客AとBの両方へアクセスするなら、ExternalIdを顧客ごとに一意に管理します。全顧客が同じ値では、代理呼出しの条件を顧客別に区別する意図が失われます。委託先が正しい値を送る運用も必要です。

5. 値だけでは不足 ExternalIdが設定されていてもPrincipalを無条件に広げてよいわけではありません。秘密パスワードとして隠すことで本人確認を代替するものでもありません。信頼する主体と顧客の条件を合わせます。

6. 正常と異常を試す 正しいExternalIdで引受け成功だけを試して終わりにせず、省略・別顧客値での拒否も確認します。引受け後は必要な参照が成功し、更新や削除が拒否されるか試します。本人確認、引受け、資源操作を一つの成功として扱いません。

7. 終了後のセッション 契約終了時に新しいAssumeRoleを禁止しても、発行済みのセッションがいつまで使えるかは別に確認します。ロールセッションの失効手順や有効期限を踏まえてアクセス終了を設計し、信頼文書の削除だけで即時完全停止と断定しません。

8. 記録から追跡 CloudTrail等で引受けと後続操作の主体を確認します。アクセスできなかった場合は両側のAllowに加えSCP等の上限も調べます。どのアカウントの主体としてどこへ要求したかを記録してから、修正すべき設定を決めます。

図解

第三者委譲の確認
ExternalIdは信頼主体の限定を置き換える秘密キーではありません。

重要ポイント

  • 相手の信頼だけでは呼出し側の許可を代替しない。
  • ExternalIdは顧客別条件として正値と異常値を試す。
  • 新規引受け停止と既存セッション終了を分ける。

間違えやすい点

  • S3拒否を信頼先の拡大で直す。
  • ExternalIdを全顧客で同じにする。
  • 既発行セッションを確認せず契約終了処理を完了する。

用語解説

呼出し側
他アカウントのロールや資源へ要求する主体がいる側。
資源側
利用させるロールやデータを管理する側。
セッション失効
既に発行したセッションの権限利用を終了させるための処理。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。