AWS Organizations SCP 規則設置解惑（工作日常）

有這一篇原因是工作上，建立 OU 時，會自動新增額外的 FullAWSAccess 規則，但原本就會有預設Root OU繼承的FullAWSAccess，等於會有兩組一樣的規則，故所以詢問了AWS Support。

先謝謝 AWS 技術支援工程師 George 細心說明～

SCP很重要的規則有以下三點:

1. SCP是定義權限的範圍並不是賦予權限

2. SCP預設都是Deny的權限，除非明確Allow相關的權限

3. Deny的權限高於Allow權限，並且Deny權限預設繼承到每一個OU和帳號上

Deny list strategy:

1. SCP預設都是Deny的權限，所以在完全沒有附加任何的SCP時，在root和OU上所有的權限都是Deny。

2. 當我們採取反向列表的方式來拒絕部分的權限時，預設都會在root和每一個OU上都自動附加FullAWSAccess。

3. 因為Deny的權限高於Allow權限並且OU也會預設繼承Deny的權限，所以該OU的範圍內將只剩下預設Deny的權限和DisableOrg，雖然有繼承FullAWSAccess，但因為OU上明確的Deny權限將完全取代繼承下來的FullAWSAccess。

Allow list strategy:

1. SCP預設都是Deny的權限，所以在完全沒有附加任何的SCP時，在root和OU上所有的權限都是Deny。

2. 我們只需要允許EC2的權限，所以在root附加FullEC2Access，這時候因為OU內預設是Deny的權限，即使FullEC2Access有繼承下來，但因為OU本身的權限優先於繼承下來的權限，所以這時候OU內還是Deny的狀態。

3. 當我們在OU上附加FullEC2Access後，因為明確的賦予EC2的權限，所以OU底下的帳號將可以擁有EC2的權限。

所以在root和每一個OU上的權限必須是明確附加的Allow權限，一旦沒有明確的附加Allow權限將會被Deny權限給取代，所以繼承的Allow權限將被OU內預設Deny的權限給取代，以下是繼承的規則:

1. SCP內如果定義Allow權限將需要在每一個需要這個權限的地方都附加上去。 2. SCP內如果定義Deny權限，將可以發揮繼承的效果，在OU或子OU上發揮作用。