【AWS】AWS Organizations（その４：SCPの継承とOU設計について）

前回からの続きです。

www.guri2o1667.work

今回は、SCPの継承とOU設計についてです。

■継承とは？

「上位に設定したSCPが下位にも影響を与える（＝下位にも設定が引き継がれる）」ということです。
「上位」とはツリー構成上の上位という意味です。
そのため、組織ルート（Root）は常に上位であり、OUは上位にも下位にもなることができます。
尚、メンバーアカウントは常に下位の立ち位置です。

■SCPの継承とは？

SCPの継承はAWS公式ドキュメントでは以下のように定義されております。
引用元：ポリシーの継承について - AWS Organizations

■SCPの継承の前提

以下の前提（仕様）があります。

①　上位SCPでDenyされたものは、下位SCPで明示的に許可していたとしてもDenyとして扱われます。（＝上位SCPのDenyは最強です）

②　暗黙のDenyが存在します。そのため、明示的に許可しない限り、全てのアクションが拒否され何もできなくなります。

③　上記②の通り、明示的な許可は暗黙のDenyより強い（優先）です。

上記①~③を纏めると強弱関係は以下の通りです。

暗黙のDeny　＜　明示的な許可　＜　明示的なDeny

■明示的な許可（Allow）について

明示的な許可を定義する方法は以下の通り2つあります。

①　ポリシー定義時のAction/Effect（JSON形式）にて明示的に記載
②　SCPにデフォルトで作成されているFullAWSAccessを使う

※上記②は①とほぼ同じ意味ですが、デフォルトで用意されておりすぐに使えるという点で記載しております。

■SCPのベストプラクティス

AWS公式ページ以下です。

【公式ページ１】

AWS Organizations のベストプラクティス - AWS Organizations

【公式ページ２】※こちらの方が読みやすかったです。

AWS Organizations における組織単位のベストプラクティス | Amazon Web Services ブログ

■SCPの設計（OU設計の前提）について

ベストプラクティスを参考にしても、いざ設計しようとすると何かと難しいです。。。

そのため、ポイントだけ記載致します。
※あくまで個人の備忘レベルです。予めご了承ください。


【公式ページ２「プロダクトおよびソフトウェア開発ライフサイクル (SDLC)」を参照】
・OUは、本番環境と開発/テスト環境では別にする。

・開発/テスト環境の使い方にばらつきがあり単一OU内に所属させることが困難な場合（＝SCPを共通で適用すると支障がある場合）には更にOUを細分化する。

・SCPはOUレベルで適用する（メンバーアカウントへのSCP適用はなるべく避ける）

■SCPの設計（OU設計）について

 公式ページ２ではOU配置について以下の用途を紹介しております。
全部で8つあります。

①　基盤（インフラOU＋セキュリティOU）
②　Sandbox
③　Workloads
④　ポリシー検証用
⑤　停止用
⑥　個々のユーザ用
⑦　例外用
⑧　CI/CD用（デプロイメント用）

上記8つを全て作成するのではなく、必要に応じて取捨選択する必要があります。
例えば、「⑥は不要」とか。

以上です。