處理請求內容運用單一帳戶評估政策決定是否允許或拒絕帳戶中的請求以身分為基礎和以資源為基礎的政策的範例明確和隱含拒絕之間的差異

政策評估邏輯

當主體嘗試使用 AWS Management Console，該 AWS API，或 AWS CLI，該主體將請求發送到 AWS。當 AWS 服務接收請求， AWS 完成數個步驟，以決定是否允許或拒絕要求。

身份驗證 — AWS 如有必要，會先驗證提出要求的主體。有少數幾個服務並不需要這個步驟，例如 Amazon S3，它允許匿名使用者的一些請求。
處理請求內容 – AWS 處理要求中收集的資訊，以決定要求套用哪些原則。
運用單一帳戶評估政策 – AWS 評估所有策略類型，這會影響評估策略的順序。
決定是否允許或拒絕帳戶中的請求 – AWS 然後根據請求內容處理策略，以確定是允許還是拒絕請求。

處理請求內容

AWS 會處理要求，將下列資訊收集到要求內容中：

動作 (或操作) – 主體想要執行的動作或操作。
資源 — AWS 執行動作或作業的資源物件。
主體 – IAM 使用者、角色、聯合身分使用者或傳送請求的應用程式。有關主體的資訊，包括與該主體相關聯的政策。
環境資料 — IP 位址、使用者代理程式、SSL啟用狀態或一天中時間的相關資訊。
資源資料 – 與所請求資源相關的資料。這可能包括 DynamoDB 表名稱或 Amazon EC2 執行個體上的標籤等資訊。

AWS 然後使用此資訊來尋找適用於請求前後關聯的原則。

運用單一帳戶評估政策

方法 AWS 評估原則取決於套用至請求前後關聯的原則類型。下列原則類型 (依頻率順序列出) 可在單一使用 AWS 帳戶。如需這些原則類型的詳細資訊，請參閱中的策略和權限 AWS Identity and Access Management。若要瞭解如何 AWS 評估跨帳戶存取的策略，請參閱跨帳戶政策評估邏輯。

以身分識別為基礎的原則 — 以身分識別為基礎的原則會附加至IAM身分識別 (使用者、使用者群組或角色)，並將權限授與IAM實體 (使用者和角色)。如果只有以身分識別為基礎的原則套用至要求，則 AWS 檢查所有這些策略至少有一個Allow。
以資源為基礎的策略 — 以資源為基礎的策略授與權限給指定為主參與者的主參與者 (帳戶、使用者、角色和工作階段主體，例如角色工作階段和IAM同盟使用者)。這些許可會定義主體可以對政策連接於其中的資源做哪些動作。如果以資源為基礎的政策和以身分識別為基礎的策略都適用於請求，則 AWS 檢查所有策略至少一個Allow。評估以資源為基礎的策略時，策略中指定的主體ARN會決定其他策略類型中的隱含拒絕是否適用於最終決定。
IAM權限界限 — 權限界限是一項進階功能，可設定以身分識別為基礎的原則可授與IAM實體 (使用者或角色) 的最大權限。當您為實體設定許可界限時，實體只能執行由以身分為基礎的政策和其許可界限同時允許的動作。在某些情況下，許可界限中的隱含拒絕會限制資源型政策所授予的許可。如需進一步了解，請參閱本主題稍後的決定是否允許或拒絕帳戶中的請求。
AWS Organizations 服務控制策略 (SCPs) — 組 Organizations SCPs 指定組織或組織單位 (OU) 的最大權限。SCP最大值適用於成員帳戶中的主參與者，包括每個主參與者 AWS 帳戶根使用者。如果存在，則SCP僅當這些策略和允許動作時，以身分識別為基礎和以資源為基礎的策略才會將權限授與成員帳戶中的主參與者。SCP如果同時存在權限界限和一個SCP，則界限SCP、和以身分識別為基礎的原則都必須允許此動作。
工作階段政策 – 工作階段政策是一種進階政策，您可以在透過編寫程式的方式建立角色或聯合身分使用者的暫時工作階段時，作為參數傳遞。若要以程式設計方式建立角色工作階段，請使用其中一項AssumeRole*API作業當您執行此操作並傳遞工作階段原則時，產生的工作階段權限是IAM實體的身分識別型原則與工作階段原則的交集。若要建立聯合使用者工作階段，您可以使用使用IAM者存取金鑰，以程式設計方式呼叫GetFederationTokenAPI作業。以資源為基礎的政策對工作階段政策許可的評估會有不同的效果。差異取決於使用者或角色的工作階段ARN是否列為以資源為基礎的策略中的主參與者。ARN如需詳細資訊，請參閱工作階段政策。

請記住，所有這類政策中的明確拒絕都會覆寫該允許。

搭配以資源為基礎的政策來評估以身分為基礎的政策

以身分為基礎的政策和以資源為基礎的政策，可為其連接到其中的身分或資源授予許可。當IAM實體 (使用者或角色) 要求存取同一帳號內的資源時， AWS 評估以身分為基礎和以資源為基礎的策略授予的所有權限。最後得到的許可總括了這兩類許可。如果以身分為基礎的策略、以資源為基礎的策略或兩者都允許動作，則 AWS 允許動作。在這些政策的明確拒絕會覆寫允許。

搭配許可界限來評估以身分為基礎的政策

當 AWS 評估以身分識別為基礎的原則和使用者的權限界限，產生的權限是這兩個類別的交集。這表示，當您新增許可界限到已有現有以身分為基礎之政策的使用者時，您可能會減少使用者可執行的動作。或者，當您移除使用者的許可界限時，您可能會增加他們可以執行的動作。在這些政策的明確拒絕會覆寫允許。若要檢視有關如何搭配許可界限來評估其他政策類型的詳細資訊，請參閱評估含界限的有效許可。

使用 Organizations 評估以身分為基礎的原則 SCPs

當使用者屬於屬於組織成員的帳戶時，產生的權限就是使用者策略與SCP. 這表示動作必須由以身分為基礎的原則和. SCP 在這些政策的明確拒絕會覆寫允許。

您可以了解您的帳戶是否為組織的成員 AWS Organizations。組織成員可能會受到SCP. 若要使用檢視此資料 AWS CLI 指令或 AWS API作業時，您必須具有「Organizations」實體organizations:DescribeOrganization動作的權限。您必須擁有其他許可，才能在 Organizations 主控台中執行操作。要了解某個人SCP是否拒絕訪問特定請求，還是要更改您的有效權限，請聯繫您的 AWS Organizations 管理員。

決定是否允許或拒絕帳戶中的請求

假設主體將要求傳送至 AWS 以存取與主參與者實體相同帳戶中的資源。所以此 AWS 強制執行代碼決定應該允許還是拒絕請求。 AWS 評估適用於請求前後關聯的所有原則。以下是一個總結 AWS 單一帳戶內原則的評估邏輯。

根據預設，所有要求都會隱含拒絕，但 AWS 帳戶根使用者，其具有完全訪問權限。
若是以身分為基礎或以資源為基礎的政策，當中的明確允許會覆寫此預設值。
如果存在權限界限SCP、Organizations 或工作階段原則，它可能會以隱含拒絕覆寫 allow。
任何政策中的明確拒絕會覆寫任何允許。

以下流程圖提供有關如何做出決策的詳細資訊。此流程圖不涵蓋以資源型政策和其他類型政策中隱含拒絕的影響。

拒絕評估 – 根據預設，所有的請求一律拒絕。這稱為隱含拒絕。所以此 AWS 強制執行程式碼會評估帳戶內套用至要求的所有策略。這些包括 AWS Organizations SCPs、以資源為基礎的原則、以身分識別為基礎的原則、IAM權限界限和工作階段原則。在所有這些政策中，強制執行程式碼會尋找套用到請求的 Deny 陳述式。此稱為明確拒絕。如果強制執行程式碼找到一個適用的明確拒絕，則程式碼會傳回拒絕的最後決定。如果沒有明確拒絕，該強制執行程式碼評估會持續執行。
Organizations SCPs — 然後強制執行代碼評估 AWS Organizations 套用至要求的服務控制原則 (SCPs)。SCPs套用至所附加帳戶的主參與者。SCPs如果強制執行程式碼在中找不到任何適用的Allow陳述式SCPs，即使拒絕是隱含的，也會明確拒絕要求。強制執行程式碼傳回拒絕的最後決定。如果沒有SCP，或者如果SCP允許要求的動作，則會繼續執行程式碼評估。

資源型政策 – 在同一帳戶內，資源型政策會根據存取資源的主體類型以及資源型政策中允許的主體，以不同的方式影響政策評估。根據主體類型，資源型政策中的 Allow 可能會導致 Allow 的最終決定，即使身分型識別政策、許可界限或工作階段政策中有隱含拒絕。

針對大部分資源，您只需要使用身分型政策或資源型政策明確允許主體，授予存取權即可。IAM角色信任原則和KMS金鑰原則是此邏輯的例外狀況，因為它們必須明確允許主體的存取權。

如果指定的主參與者是IAM使用者、IAM角色或工作階段主體，則以資源為基礎的原則邏輯與其他原則類型不同。工作階段主體包括IAM角色工作階段或IAM同盟使用者工作階段。如果以資源為基礎的原則將權限直接授與IAM使用者或正在發出要求的工作階段主體，則以身分識別為基礎的原則、權限界限或工作階段原則中的隱含拒絕不會影響最終決定。

下表可協助您瞭解當身分識別型政策、許可界限和工作階段政策中出現隱含拒絕時，資源型政策會針對不同主體類型產生何種影響。

下表顯示相同帳戶的其他策略類型中以資源為基礎的策略和隱含拒絕。

主體發出要求	以資源為基礎政策	身分型政策	許可界限	工作階段政策	結果	原因
IAM角色	不適用	不適用	不適用	不適用	不適用	角色本身無法提出要求。假定角色之後，會使用角色工作階段提出要求。
IAM角色會話	允許角色 ARN 或允許角色會話 ARN	隱含拒絕	隱含拒絕	隱含拒絕	DENY-角色 ARN 或 ALLOW-角色工作階段 ARN	當以資源為基礎的原則中的主參與者是角色時ARN，會將權限界限和工作階段原則評估為最終決定的一部分。任一策略中的隱含拒絕都會導致DENY決策。當以資源為基礎的原則中的主參與者是角色工作階段時ARN，權限會直接授與工作階段。其他政策類型不會影響決定。
IAM使用者	允許IAM使用者 ARN	隱含拒絕	隱含拒絕	不適用	ALLOW	許可直接授予使用者。其他政策類型不會影響決定。
IAM同盟使用者 () `GetFederationToken`	允許IAM使用者 ARN 或允許IAM同盟使用者工作階段 ARN	隱含拒絕	隱含拒絕	隱含拒絕	DENY-IAM 用戶 ARN 或 ALLOW-IAM 聯合使用者工作階段 ARN	當以資源為基礎的策略中的主體是IAM使用者時ARN，權限界限或工作階段策略中的隱含拒絕會導致. DENY 當以資源為基礎的原則中的主參與者是IAM同盟使用者工作階段時ARN，權限會直接授與工作階段。其他政策類型不會影響決定。
根使用者	允許根使用者 ARN	不適用	不適用	不適用	ALLOW	root 使用者可以完整、不受限制地存取您中的所有資源 AWS 帳戶。若要瞭解如何控制對於帳號的 root 使用者存取 AWS Organizations，請參閱《Organizations 使用指南SCPs》中的服務控制策略 ()。
AWS 服務主體	允許 AWS 服務主體	不適用	不適用	不適用	ALLOW	當以資源為基礎的策略直接授與權限 AWS 服務主體，其他原則類型不會影響決定。

IAMrole — 授與角色權限的以資源為基礎的策略IAM受到權限界限或工作階段策略中隱含拒絕的限制。ARN您可以ARN在「主參與者」元素或aws:PrincipalArn條件索引鍵中指定角色。在這兩種情況下，提出要求的主體都是IAM角色工作階段。

除非身分識別型原則包含明確拒絕，否則權限界限和工作階段原則不會限制使用具有萬用字元 (*) 的aws:PrincipalArn條件金鑰授予的權限。如需詳細資訊，請參閱IAM角色主參與者。

角色範例 ARN
```
arn:aws:iam::111122223333:role/examplerole
```
IAMrole session — 在同一帳戶中，將權限授與角IAM色工作階段的以資源為基礎的策略直接ARN授與權限給假定的角色工作階段。直接授予工作階段的許可不會受到身分識別型政策、許可界限或工作階段政策中隱含拒絕的限制。當您擔任角色並提出要求時，提出要求的主參與者是角色工作階段，ARN而不是IAM角色本身ARN的角色工作階段。如需詳細資訊，請參閱角色工作階段主體。

角色工作階段範 ARN
```
arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
```
IAMuser — 在同一帳戶內，將權限授與IAM使用者 ARN (非同盟使用者工作階段) 的資源型策略不受身分型策略或權限界限中隱含拒絕的限制。

IAM使用者範例 ARN
```
arn:aws:iam::111122223333:user/exampleuser
```
IAM聯合使用者工作階段 — IAM 聯合使用者工作階段是透過呼叫建立的工作階段。GetFederationToken當同盟使用者提出要求時，提出要求的主參與者是同盟使用者，ARN而不是同盟ARN的使IAM用者。在同一帳戶中，將權限授與聯合使用者的以資源為基礎的政策會直接ARN授與工作階段的權限。直接授予工作階段的許可不會受到身分識別型政策、許可界限或工作階段政策中隱含拒絕的限制。

不過，如果以資源為基礎的政策授與聯合IAM使用者ARN的權限，則同盟使用者在工作階段期間所提出的要求會受到權限界限或工作階段原則中隱含拒絕的限制。

IAM同盟使用者工作階段範例 ARN
```
arn:aws:sts::111122223333:federated-user/exampleuser
```

以身分為基礎的政策 – 程式碼接著會檢查主體的以身分為基礎的政策。對於IAM使用者而言，其中包括使用者所屬群組的使用者策略和策略。如果沒有任何身分型政策或其中的任何陳述式允許該要求動作，則表示要求已遭隱含拒絕，且程式碼會傳回拒絕的最終決定。如果任何適用的身分型政策中有任一陳述式允許該要求動作，則程式碼會繼續執行。
IAM權限界限 — 然後程式碼會檢查主參與者所使用的IAM實體是否具有權限界限。如果用來設定許可界限的政策不允許該請求動作，則表示請求已遭隱含拒絕。程式碼傳回拒絕的最後決定。如果許可界限不存在，或是許可界限允許請求動作，程式碼就會繼續執行。
工作階段政策 – 程式碼接著會檢查主體是否為工作階段主體。工作階段主體包括IAM角色工作階段或IAM同盟使用者工作階段。如果主體不是工作階段主體，則強制執行程式碼會傳回允許的最終決定。

對於工作階段主體，程式碼檢查工作階段政策是否在要求中傳遞。您可以在使用時傳遞工作階段原則 AWS CLI 或 AWS API取得角色或IAM同盟使用者的臨時認證。
- 如果工作階段政策存在，且不允許該要求動作，則表示要求已遭隱含拒絕。程式碼傳回拒絕的最後決定。
- 如果工作階段政策不存在，程式碼會檢查主體是否為角色工作階段。如果主體是角色工作階段，則要求為已允許。否則，要求會受到婉拒，程式碼則會傳回拒絕的最終決定。
- 如果有工作階段政策，且政策允許該要求動作，則強制執行程式碼會傳回允許的最終決定。
錯誤 — 如果 AWS 強制代碼在評估過程中的任何時候遇到錯誤，然後產生一個異常並關閉。

以身分為基礎和以資源為基礎的政策的範例

最常見的政策類型是以身分為基礎的政策和以資源為基礎的政策。當請求訪問資源時， AWS 評估策略授與至少一個 [允許] 在同一帳戶中的所有權限。所有政策中的明確拒絕都會覆寫該允許。

重要

如果在相同帳戶中，身分型政策和資源型政策中的任意一項政策允許請求而另一項不允許，則請求仍將被允許。

假設 Carlos 有使用者名稱 carlossalazar，他嘗試儲存檔案到 amzn-s3-demo-bucket-carlossalazar-logs Amazon S3 儲存貯體。

同時假設下列原則已附加至carlossalazarIAM使用者。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowS3Self",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
                "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
            ]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*log*"
        }
    ]
}

此政策中的 AllowS3ListRead 陳述式允許 Carlos 檢視帳戶中的所有儲存貯體的清單。AllowS3Self 陳述式允許 Carlos 完整存取名稱和他的使用者名稱完全相同的儲存貯體。DenyS3Logs 陳述式拒絕 Carlos 存取名稱中包含 log 的任何 S3 儲存貯體。

此外，以下以資源為基礎的政策 (稱為儲存貯體政策) 已連接到 amzn-s3-demo-bucket-carlossalazar 儲存貯體。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/carlossalazar"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
                "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
            ]
        }
    ]
}

此政策指定只有 carlossalazar 使用者可以存取 amzn-s3-demo-bucket-carlossalazar 儲存貯體。

當 Carlos 提出將文件保存到存儲amzn-s3-demo-bucket-carlossalazar-logs桶的請求時， AWS 決定要套用至要求的原則。在這種情況下，只有以身分為基礎的政策和以資源為基礎的政策適用。這兩者都是許可政策。由於未套用許可界限，評估邏輯會降低到以下邏輯。

AWS 首先檢查適用於請求上下文的Deny語句。它找到一個，因為以身分為基礎的政策明確拒絕 Carlos 存取任何用於記錄的 S3 儲存貯體。Carlos 存取遭拒。

假設他然後意識到自己的錯誤，並試圖將文件保存到存儲amzn-s3-demo-bucket-carlossalazar桶。 AWS 檢查Deny陳述式，但找不到陳述式。接著檢查許可政策。身分類型政策和資源類型政策都允許請求。因此， AWS 允許請求。如果其中一個元素明確拒絕陳述式、請求會被拒絕。如果其中一種政策類型允許請求，但另一種則不允許，則仍會允許請求。

明確和隱含拒絕之間的差異

如果適用的請求包含 Deny 陳述式，請求會導致明確拒絕。如果套用到請求的政策包含 Allow 陳述式和 Deny 陳述式，則 Deny 陳述式勝過 Allow 陳述式。請求明確遭拒。

如果沒有適用的 Deny 陳述式，也沒有適用的 Allow 陳述式，則會發生暗中拒絕。由於IAM主參與者預設為拒絕存取，因此必須明確允許他們執行動作。否則，會暗中拒絕他們存取。

當您設計授權策略時，您必須建立具 Allow 陳述式的政策，讓您的主體成功發出請求。不過，您可以選擇明確和暗中拒絕的任意組合。

例如，您可以建立下列政策，其中包含允許的動作、隱含拒絕的動作以及明確拒絕的動作。該AllowGetList語句允許對以前綴Get和List開頭的IAM操作進行只讀訪問。中的所有其他動作IAM，例如iam:CreatePolicy會隱含拒絕。DenyReports陳述式會拒絕存取包含Report尾碼的動作 (例如)，明確拒絕存取IAM報表。iam:GetOrganizationsAccessReport如果有人新增另一個原則至此主參與者以授與他們存取IAM報表 (例如)iam:GenerateCredentialReport，報表相關要求仍會因為此明確拒絕而遭到拒絕。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGetList",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyReports",
            "Effect": "Deny",
            "Action": "iam:*Report",
            "Resource": "*"
        }
    ]
}

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

支援的資料類型

跨帳戶政策評估邏輯