メンバーアカウントがOrganizationsから抜けられないSCPを試した

OUを作っただけでは、まだ制御していなかった

第7回では、samekoro-labをLab OUへ、samekoro-prodをProd OUへ配置しました。役割は見やすくなりましたが、その時点では分類しただけです。

次に試したかったのは、OUへルールを適用するとメンバーアカウント側の操作が本当に止まるのかということでした。SCPという言葉は知っていても、自分のアカウントで拒否されるところを見るまでは、どこまで効くのかを実感できていませんでした。

SCPはService Control Policyの略で、Organizations内のメンバーアカウントで利用できる権限の上限を定めるガードレールです。権限を新しく与えるポリシーではありません。

この説明を読んでも、最初はAdministratorAccessを持つ管理者なら操作できるのでは、と考えました。アカウントの管理者権限と、組織側からかける制御の関係が頭の中で混ざっていたからです。

そこで、結果が分かりやすく、検証範囲をLab OUに限定できる操作として、組織からの離脱を止めるルールを試しました。

作成したSCPの名前はDenyLeaveOrganizationです。対象は、メンバーアカウントがOrganizationsから離脱する操作です。

今回は組織全体やProd OUへ広げず、Lab OUへ適用しました。AWS公式資料でも、SCPは影響を確認しながら小さな単位で試すことが勧められています。自分の環境でも、まず検証用として分けた場所へ付けるのが自然でした。

ポリシー名、適用先、止めたい操作を一つに絞ったことで、確認時に何が原因で拒否されたのかを追いやすくしました。

適用しただけでは、設定が存在することしか分かりません。samekoro-lab側から組織を離れる操作を試し、実行できないことを確認しました。

ここで見たかったのは特定のエラー文ではなく、メンバーアカウント側に管理者権限があっても、Organizations側で明示的に拒否した操作は通らないという結果です。

拒否を確認して、SCPが「各アカウントへ同じ権限設定を配るもの」ではないことがはっきりしました。各アカウントの権限とは別の層で、越えてはいけない上限を置いています。

ここで一度、SCPがあればIAM側の権限を考えなくてよいのか、と逆方向にも迷いました。しかし、SCPは許可を付けるものではありません。

利用者やロールへ何を許可するかはIAM側で決め、そのうえでOrganizations側のSCPが最大範囲を絞ります。今回なら、AdministratorAccessが操作を許可していても、Lab OUのSCPが離脱を拒否しているため実行できません。

二つを同じ「権限設定」としてまとめず、役割を分けて考える必要がありました。

企業なら、組織からの離脱はアカウント管理や請求、監査にも関わります。SCPの変更手順、例外、レビュー、復旧経路まで決めて運用するはずです。

今回は個人の検証環境なので、Lab OUという限定した場所で、ポリシーを付けた結果を自分で確認できました。大きなルールを先に増やすのではなく、一つの拒否を最後まで追うことで、SCPの役割を理解することを優先しました。

DenyLeaveOrganizationをLab OUへ適用し、samekoro-labがOrganizationsから離脱できないことを確認しました。

分かったのは、管理者権限の強さだけでは決まらない制御があることです。SCPは権限を与えず、メンバーアカウントが越えられない上限を組織側に置きます。

次は、分けた三つのAWSアカウントへIAM Identity Centerから入るために、ユーザー・グループ・許可セット・割り当てをどうつないだかを整理します。