AWS OrganizationsとSCPのシナリオ判断

SCPの許可集合、OU移動、外部主体のアクセスを具体例で読み、管理者でも越えない境界を判断します。

この単元で学ぶこと

  • 階層別の許容を事例で計算する
  • 対象外主体を誤解なく判断する
  • 組織変更による影響を切り分ける

本文解説

1. 狭いAllowを足した例 OUにFullAWSAccessが残る状態でGetObjectだけのAllowを追加しても、その階層の許容がGetObjectだけにはなりません。同階層のAllowは合わせて評価されます。絞る設計なら既存の許容も含めて変更します。

2. 親が許していない例 メンバーIDとアカウントSCPはGetObjectとPutObjectを許可しても、親OUがGetObjectしか許容しなければPutObjectは使えません。子側へ同じAllowを足す対応では親の上限を変えられません。

3. 拒否を追加した例 全階層にAllowがあっても、組織ルートでGetObjectを明示的Denyしたら、対象のメンバー主体はGetObjectを使えません。PutObjectにDenyがなければ、その操作は別に評価します。一つのAPIの拒否を全操作拒否と読み替えないでください。

4. 全て止まった例 唯一のSCP Allowをある階層から外すと、配下に広いIAM権限があっても操作が止まり得ます。SCPが権限付与ではないから削除しても影響しない、という解釈は誤りです。許容上限の消失を調べます。

5. 管理者の種類 管理アカウント、委任管理者のメンバー、メンバーrootを区別します。前者の主体はSCP対象外ですが、後二つは対象です。サービスリンクロールの例外も、一般のEC2等のサービスロールへ拡張しません。

6. 外部共有が残る例 組織内バケットへ組織外のユーザーが資源ポリシーで許可されている場合、バケット所有アカウントのSCPだけでその外部ユーザーを直接制限したとはいえません。資源側の許可や公開防止等を別に調べます。

7. 移動後の復旧操作 アカウント移動後に復旧APIが使えなくなったら、新しいOUの継承経路と実際の主体を確認します。管理者権限の再付与ではSCPの不足やDenyを解決できません。事前の検証範囲に復旧・監視・運用も入れます。

8. 検証の前提 本単元の集合問題は対象メンバーIDの通常要求で、資源側付与や記載以外の制限を除いています。実環境ではその前提を確認してから利用し、必要な操作成功と禁止操作失敗を記録します。例外を設けるときも対象と変更権限を明確にします。

図解

広いAllowが残る同一OU
狭いAllow追加と、既存の許容範囲の縮小は同じではありません。

重要ポイント

  • 同階層の広いAllowが残ると狭いAllow追加だけでは絞れない。
  • 親の上限と明示的Denyを子は越えない。
  • 主体の所属とロール種類でSCP対象を判定する。

間違えやすい点

  • 権限を付与しないSCPなら外しても影響なしと思う。
  • 委任管理者をSCP適用外とする。
  • 資源所有者のSCPで外部主体も直接制限済みとする。

用語解説

SCPの許容
主体が操作するために必要な組織側の上限の許可。
明示的拒否
条件に合う要求をDeny文によって拒否すること。
段階適用
少数の検証対象から影響を確かめながら適用範囲を広げること。

関連教材

参考資料

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

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