AWS OrganizationsとSCPのシナリオ判断

組織加入後のアクセス拒否、管理者でもできない操作、OU移動の影響を独立した事例で判断します。

この単元で学ぶこと

  • 請求管理と操作許可を事例で区別する
  • SCPの適用先を判定する
  • 上位制限と変更手順を判断する

本文解説

1. 組織に入ったのに読めない アカウントBが同じ組織に加入しても、Aのデータを読む権限が自動で生じるわけではありません。請求をまとめる要件と、別アカウントの資源へアクセスする要件を分け、必要な許可を別途設計します。

2. 全操作Allowの誤解 SCPのFullAWSAccessを見て、新しいIAMユーザーが全操作できると思い込む例があります。このSCPは組織側の上限を許容するもので、ユーザーに権限を付与する文書ではありません。IAM等の実際の許可を調べます。

3. 管理者にも拒否 本番OUで禁止した操作が、メンバーのAdministratorAccessユーザーでも拒否されたとします。IAMへ同じAllowを追加しても上位Denyは消えません。禁止理由を確認し、必要なら組織方針側の承認された変更を検討します。

4. rootでの再試行 メンバーアカウントのrootへ切り替えればSCPを迂回できるとは限りません。SCPに対象外として列挙される操作等を除き、メンバーrootも制限対象です。管理アカウントの主体がSCP対象外であることと混同しないでください。

5. 委任管理 監査サービスの管理をメンバーへ委任しても、そのアカウントはOrganizations管理アカウントにはなりません。引き続きSCPを評価します。また、サービスが使う一般ロールとサービスリンクロールの違いも確認します。

6. OU移動後の失敗 開発OUで使えていたAPIが本番OUへ移動後に拒否された場合、移動先までの上位制限を調べます。アカウント内のIAMを変えていなくても、組織側の許容範囲は変わり得ます。

7. 請求のみの設定 一括請求だけのOrganizationsでSCPを使おうとしている場合、全機能の設定を確認します。サービスの名称だけで任意の機能が有効だと判断しません。変更時には管理対象や影響も確認します。

8. 本番への段階適用 禁止を増やすSCPは検証OU等で試します。必要な運用、監視、復旧の操作が使えるかも確認します。全体に適用してから問題を探すのではなく、対象を限定して成功と拒否の期待を記録します。

図解

OU移動後の拒否を調べる
アカウント内のIAMが同じでも、組織側の上限は変わり得ます。

重要ポイント

  • 同じ組織でも資源アクセスは別途設計する。
  • メンバー管理者やrootでもSCPを無条件には越えない。
  • OU移動やSCP変更には影響確認が必要。

間違えやすい点

  • 管理者ポリシーを増やして上位拒否を打ち消す。
  • 委任管理者を管理アカウントと同一視する。
  • 請求統合を権限統合と考える。

用語解説

委任管理者
特定AWSサービスの組織管理を任されたメンバーアカウント。
FullAWSAccess
SCPとして全操作を許容する規則で、IAMの管理者権限付与とは別。
継承経路
組織ルートからOUを経由して対象アカウントへ至る制限の経路。

関連教材

参考資料

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

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