開発チームへ、同一アカウント内のアプリケーション用IAMロール作成とIDベースポリシーの付与を委任する。中央管理者が承認済みの境界ポリシーを管理する。
アプリケーションロールのIDベース権限を境界内へ制限し、境界なしの作成や境界の削除・差替えによる回避も防ぐ。開発チームは承認済み境界ポリシーの内容を編集できない。
信頼ポリシーとiam:PassRoleの許可範囲は別途限定済みである。リソースポリシーからロールセッションへの直接許可や、他のSCP・セッションポリシーによる制限は本問に含めない。
この委任方式に組み合わせる設計として適切なものはどれか。
承認済みPermissions boundaryを作成先ロールへ必須化し、削除や差替えによる回避を防ぐ。境界は権限を付与せず、IDベースポリシーの許可範囲との共通部分が有効になる。
詳細解説
広いIDベースAllowを追加しても境界の上限を越えない。必要な権限の付与と、最大範囲の制限を分けて評価する。
境界は単独では権限を付与しない。本問ではアプリケーションに必要なIDベースポリシーのAllowも必要である。
作成先への必須化と回避操作の制限を組み合わせる。本問の権限はIDベースポリシーと境界の両方で許可される範囲になる。
開発者自身の境界は、作成先ロールの境界として自動継承されない。作成先への設定を別途必須化する必要がある。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料と作成先ロールのPermissionsBoundary ARN、IDベースポリシー、開発チームのCreateRole条件と境界削除・差替え権限、境界ポリシーの編集権限を照合する。承認済み環境では境界なしの作成と境界変更の拒否、両方で許可する操作の成功、IDベースポリシーだけが許可する境界外操作の拒否を比較する。
参考にした公式資料
確認できる内容
作成先ロールに承認済み境界が付き、開発チームによる境界なし作成・削除・差替えは拒否される。本問のIDベース評価では両方が許可した操作だけが可能となり、AdministratorAccessを追加しても境界外の操作は許可されない。
理解のポイント
- Permissions boundary
- iam:PermissionsBoundary
- IDベースポリシー
確認時の注意
- 確認環境: 公式IAM資料の確認。必要に応じ承認済み環境で権限評価を比較する。
- AWS公式SAA-C03 Domain 1と各サービスの公式ドキュメントを確認する。
基礎のおさらい
作成者と作成先の境界は別である
開発者自身のPermissions boundaryは、開発者が作成するロールへ自動継承されない。CreateRoleの許可でiam:PermissionsBoundary条件を使うなどして承認済み境界を必須化し、削除・差替えや境界ポリシーの改変も制限する。
権限付与と最大範囲を分ける
本問のIDベース評価では、権限ポリシーと境界の両方が許可する操作だけが有効になる。境界だけでは権限は得られず、AdministratorAccessの追加でも境界外の操作は許可されない。明示的DenyがあればAllowより優先する。
委任の他の経路も別に設計する
境界を付けるだけで信頼ポリシーやiam:PassRoleの安全性まで保証されるわけではない。またリソースポリシーからロールセッションへ直接付与される権限には別の評価規則がある。本問はそれらを除外し、作成先ロールのIDベース権限の上限を比較している。