本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

SCP 評估

由於可以在 AWS Organizations中連接不同層級的多個服務控制政策 (SCP)，因此理解 SCP 的評估方式可協助您撰寫產生正確結果的 SCP。

SCP 如何使用允許陳述式

對於為特定帳戶允許的許可，每個層級都必須有明確的 Allow 陳述式，範圍從根目錄到帳戶直接路徑中的每個 OU (包括目標帳戶本身)。因此，當您啟用 SCPs 時， 會 AWS Organizations 連接名為 FullAWSAccess 的 AWS 受管 SCP 政策，以允許所有服務和動作。如果移除此政策且未在組織的任何層級取代，則該層級下的所有 OU 和帳戶都會遭到封鎖，無法執行任何動作。

例如，讓我們逐步瀏覽圖 1 和圖 2 中顯示的場景。對於在帳戶 B 中允許的許可或服務，應將允許此許可或服務的 SCP 連接至根、生產 OU 和帳戶 B 本身。

SCP 評估遵循預設拒絕模型，這意味著 SCP 中未明確允許的任何許可都將被拒絕。如果在 SCP 中的任何層級 (例如根目錄、生產 OU 或帳戶 B) 均沒有允許陳述式，則會拒絕存取。

圖 1：在根、生產 OU 和帳戶 B 中連接 Allow 陳述式的範例組織結構

圖 2：生產 OU 中缺少 Allow 陳述式的範例組織結構及其對帳戶 B 的影響

SCP 如何使用拒絕陳述式

對於為特定帳戶拒絕的許可，從根目錄到帳戶直接路徑中的每個 OU (包括目標帳戶本身) 的任何 SCP 都可以拒絕該許可。

例如，假設有一個 SCP 連接至生產 OU，該 SCP 具有針對特定服務指定的明確 Deny 陳述式。剛好有另一個 SCP 連接至根和帳戶 B，其明確允許存取該相同的服務，如圖 3 所示。因此，帳戶 A 和帳戶 B 都會遭到拒絕存取該服務，因為系統會針對所有 OU 和成員帳戶評估連接至組織中任何層級的拒絕政策。

圖 3：在生產 OU 中連接 Deny 陳述式的範例組織結構及其對帳戶 B 的影響

使用 SCP 的策略

撰寫 SCPs 時，您可以使用 Allow和 Deny陳述式的組合來允許組織中的預期動作和服務。 Deny陳述式是實作對組織或 OUs 的更廣泛部分應成立限制的強大方式，因為當它們套用到根帳戶或 OU 層級時，它們會影響其下的所有帳戶。

例如，您可以使用 Deny 陳述式 防止成員帳戶離開組織。在根層級對 實作政策，這將對組織中的所有帳戶有效。拒絕陳述式也支援可協助建立例外狀況的條件元素。

AWS Organizations 建立 AWS 受管 SCP 時，會將名為 FullAWSAccess 的受管 SCP 連接到每個根目錄、OU 和帳戶。此政策會允許所有服務和動作。您可以使用僅允許一組服務的政策取代 FullAWSAccess，因此 AWS 服務 除非更新 SCPs 明確允許新服務，否則不允許新服務。例如，如果您的組織只想要允許在環境中使用服務子集，可以使用 Allow 陳述式來僅允許特定的服務。

JSON

{
"Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        }
    ]
}

結合這兩種陳述式的政策可能如以下範例所示，其中會阻止成員帳戶離開組織並允許使用所需的 AWS 服務。組織管理員可以分離 FullAWSAccess 政策，並改為連接此政策。

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny", 
            "Action":"organizations:LeaveOrganization",
            "Resource": "*" 
        }
    ]
}

若要示範如何在 組織中套用多個服務控制政策 AWS (SCPs)，請考慮下列組織結構和案例。

案例 1：拒絕政策的影響

此案例示範組織中更高層級的拒絕政策如何影響以下所有帳戶。當沙盒 OU 同時具有「完整 AWS 存取」和「拒絕 S3 存取」政策，且帳戶 B 具有「拒絕 EC2 存取」政策時，結果是帳戶 B 無法存取 S3 （來自 OU 層級拒絕） 和 EC2 （來自其帳戶層級拒絕）。帳戶 A 沒有 S3 存取權 （來自 OU 層級拒絕）。

案例 2：允許政策必須存在於每個層級

此案例顯示允許政策如何在 SCPs中運作。若要存取服務，從根目錄到帳戶的每個層級都必須有明確的允許。在這裡，由於沙盒 OU 具有「允許 EC2 存取」政策，只明確允許 EC2 服務存取，因此帳戶 A 和 B 將只具有 EC2 存取。

案例 3：在根層級缺少允許陳述式的影響

在 SCP 根層級缺少「允許」陳述式是一種嚴重的錯誤設定，可有效封鎖組織中所有成員帳戶對 AWS 服務和動作的所有存取。

案例 4：分層拒絕陳述式和產生的許可

此案例示範兩層深度 OU 結構。根和工作負載 OU 都具有「完整 AWS 存取」，測試 OU 具有「拒絕 EC2 存取」的「完整 AWS 存取」，而生產 OU 具有「完整 AWS 存取」。因此，帳戶 D 具有 EC2 和帳戶 E 和 F 以外的所有服務存取權，具有所有服務存取權。

案例 5：允許 OU 層級的政策限制服務存取

此案例說明如何使用允許政策來限制對特定 服務的存取。測試 OU 具有「允許 EC2 存取」政策，這表示帳戶 D 僅允許 EC2 服務。生產 OU 維護「完整 AWS 存取」，因此帳戶 E 和 F 可存取所有服務。這示範如何在 OU 層級實作更嚴格的允許政策，同時在根層級維持更廣泛的允許。

案例 6：根層級拒絕會影響所有帳戶，無論較低層級允許

此案例顯示根層級的拒絕政策會影響組織中的所有帳戶，無論較低層級的允許政策為何。根目錄同時具有「完整 AWS 存取」和「拒絕 S3 存取」政策。即使測試 OU 具有「允許 S3 存取」政策，以根層級 S3 拒絕為優先。帳戶 D 沒有服務存取權，因為測試 OU 只允許 S3 存取，但在根層級拒絕 S3。帳戶 E 和 F 可以存取 S3 以外的其他服務，因為根層級明確拒絕。