本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # AWS 強制執行程式碼邏輯如何評估允許或拒絕存取的請求 AWS 強制執行程式碼會決定是否 AWS 應該允許或拒絕傳送至 的請求。 會 AWS 評估適用於請求內容的所有政策。以下是 AWS 政策評估邏輯的摘要。 + 根據預設，所有的要求會一律拒絕 ( AWS 帳戶根使用者提出的要求例外，該使用者具有完整存取權)。 + 允許以下評估邏輯後，請求必須得到某個政策或一組政策的明確允許。 + 明確拒絕會覆寫明確允許。 政策評估可能會因請求是在單一帳戶內還是跨帳戶而有所不同。如需有關如何為單一帳戶內的 IAM 角色或使用者作出政策評估決策的詳細資訊，請參閱[單一帳戶中請求的政策評估](reference_policies_evaluation-logic_policy-eval-basics.md)。如需有關如何針對跨帳戶請求作出政策評估決策的詳細資訊，請參閱[跨帳戶政策評估邏輯](reference_policies_evaluation-logic-cross-account.md)。 + **拒絕評估** – 根據預設，所有的請求一律拒絕。這稱為[隱含拒絕](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md)。 AWS 強制執行程式碼會評估帳戶內套用至請求的所有政策。這些包括 AWS Organizations SCPs和 RCPs、資源型政策、身分型政策、IAM 許可界限和工作階段政策。在所有這些政策中，強制執行程式碼會尋找套用到請求的 `Deny` 陳述式。此稱為[明確拒絕](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md)。如果強制執行程式碼找到一個適用的明確拒絕，則強制執行程式碼會傳回**拒絕**這一最後決定。如果沒有明確拒絕，該強制執行程式碼評估會持續執行。 + **AWS Organizations RCPs** – 強制執行程式碼會評估套用至請求 AWS Organizations 的資源控制政策 (RCPs)。RCP 適用於 RCP 所連接的帳戶資源。如果強制執行程式碼在 RCP 中找不到任何適用的 `Allow` 陳述式，則強制執行程式碼會傳回**拒絕**這一最終決定。請注意，啟用 RCP 時，會自動建立名為 AWS 的 `RCPFullAWSAccess` 受管政策並連接到組織中的每個實體，包括根實體、每個 OU 以及 AWS 帳戶 。`RCPFullAWSAccess` 無法分離，因此始終會有 `Allow` 陳述式。如果 RCP 不存在，或 RCP 允許請求的動作，強制執行程式碼評估就會繼續執行。 + **AWS Organizations SCPs** – 強制執行程式碼會評估套用至請求 AWS Organizations 的服務控制政策 (SCPs)。SCP 會套用至連接 SCP 的帳戶之主體。如果強制執行程式碼在 SCP 中找不到任何適用的 `Allow` 陳述式，則強制執行程式碼會傳回**拒絕**這一最終決定。如果 SCP 不存在，或是 SCP 允許請求動作，強制執行程式碼評估就會繼續執行。 + **資源型政策** – 在同一帳戶內，資源型政策會根據存取資源的主體類型以及資源型政策中允許的主體，以不同的方式影響政策評估。根據主體類型，資源型政策中的 `Allow` 可能會導致 `Allow` 的最終決定，即使身分型識別政策、許可界限或工作階段政策中有隱含拒絕。 針對大部分資源，您只需要在身分型政策或資源型政策中對主體提供明確 `Allow`，即可授予存取權。[IAM 角色信任政策](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies)和 [KMS 金鑰政策](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)是此邏輯的例外，因為這些政策必須明確允許存取[主體](reference_policies_elements_principal.md)。對於 IAM 和 AWS KMS 以外的服務，資源型政策可能也需要在同一帳戶內具有明確的 `Allow` 陳述式才能授予存取權。如需詳細資訊，請參閱適用於您所使用之特定服務的文件。 對於單一帳戶政策評估請求，如果指定的主體是 IAM 使用者、IAM 角色或工作階段主體，資源型政策邏輯會與其他政策類型有所不同。工作階段主體包括 [IAM 角色工作階段](reference_policies_elements_principal.md#principal-role-session)或 [AWS STS 聯合身分使用者主體](reference_policies_elements_principal.md#sts-session-principals)。如果資源型政策直接將許可授予 IAM 使用者或提出要求的工作階段主體，則身分識別型政策、許可界限或工作階段政策中的隱含拒絕不會影響最終決定。 + **IAM 角色** – 將許可授予 IAM 角色 ARN 的資源型政策受限於許可界限或工作階段政策中隱含拒絕的限制。您可以在主體元素或 `aws:PrincipalArn` 條件索引鍵中指定角色 ARN。在這兩種情況下，發出請求的主體是 **IAM 角色工作階段**。 許可界限和工作階段政策不會限制在主體元素中使用 `aws:PrincipalArn` 條件索引鍵與萬用字元 (\$1) 所授予的許可，除非身分型政策包含明確拒絕。如需詳細資訊，請參閱[IAM 角色主體](reference_policies_elements_principal.md#principal-roles)。 **角色 ARN 範例** ``` arn:aws:iam::111122223333:role/examplerole ``` + **IAM 角色工作階段** – 在同一帳戶內，將許可授予 IAM 角色工作階段 ARN 的資源型政策直接授予許可給擔任的角色工作階段。直接授予工作階段的許可不會受到身分識別型政策、許可界限或工作階段政策中隱含拒絕的限制。當您擔任角色並提出要求時，提出要求的主體是 IAM 角色工作階段 ARN，而不是角色本身的 ARN。如需詳細資訊，請參閱[角色工作階段主體](reference_policies_elements_principal.md#principal-role-session)。 **角色工作階段 ARN 範例** ``` arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname ``` + **IAM 使用者** – 在同一帳戶內，將許可授予 IAM 使用者 ARN (非聯合身分使用者工作階段) 的資源型政策不受身分識別型政策或許可界限中隱含拒絕的限制。 **IAM 使用者 ARN 範例** ``` arn:aws:iam::111122223333:user/exampleuser ``` + **AWS STS 聯合身分使用者主體** – 聯合身分使用者工作階段是透過呼叫 建立的工作階段[`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken)。當聯合身分使用者提出要求時，提出要求的主體是聯合身分使用者 ARN，而不是聯合身分 IAM 使用者的 ARN。在相同的帳戶中，授予許可給聯合身分使用者 ARN 的資源型政策會直接將許可授予工作階段。直接授予工作階段的許可不會受到身分識別型政策、許可界限或工作階段政策中隱含拒絕的限制。 但是，如果資源型政策向聯合身分 IAM 使用者 ARN 授予許可，則聯合身分使用者在工作階段期間提出的要求會受到許可界限或工作階段政策中隱含拒絕的限制。 **聯合身分使用者工作階段 ARN 範例** ``` arn:aws:sts::111122223333:federated-user/exampleuser ``` + **身分型政策**：強制執行程式碼會檢查主體的身分型政策。若為 IAM 使用者，這些政策會包含使用者政策，以及使用者所屬群組的政策。如果沒有任何身分型政策或其中的任何陳述式允許請求的動作，則表示請求已遭隱含拒絕，且強制執行程式碼會傳回**拒絕**這一最終決定。如果任何適用的身分型政策中有任一陳述式允許請求的動作，則程式碼評估會繼續執行。 + **IAM 許可界限**：強制執行程式碼會檢查主體所使用的 IAM 實體是否有許可界限。如果用來設定許可界限的政策不允許該請求動作，則表示請求已遭隱含拒絕。強制執行程式碼傳回**拒絕**的最後決定。如果許可界限不存在，或是許可界限允許請求的動作，程式碼評估就會繼續執行。 + **工作階段政策**：強制執行程式碼會檢查主體是否為工作階段主體。工作階段主體包括 IAM 角色工作階段或 AWS STS 聯合身分使用者工作階段。如果主體不是工作階段主體，則強制執行程式碼會傳回**允許**的最終決定。 對於工作階段主體，強制執行程式碼會檢查工作階段政策是否已在請求中傳遞。您可以在使用 AWS CLI 或 AWS API 取得角色或 AWS STS 聯合身分使用者主體的臨時登入資料時，傳遞工作階段政策。如果未傳遞工作階段政策，則會建立預設工作階段政策，且強制執行程式碼會傳回**允許**這一最終決定。 + 如果工作階段政策存在，且不允許該要求動作，則表示要求已遭隱含拒絕。強制執行程式碼傳回**拒絕**的最後決定。 + 強制執行程式碼會檢查主體是否為角色工作階段。如果主體是角色工作階段，則請求將為**已允許**。否則，會隱含拒絕請求，強制執行程式碼會傳回**拒絕**這一最終決定。 + 如果有工作階段政策，且政策允許該要求動作，則強制執行程式碼會傳回**允許**的最終決定。 # 單一帳戶中請求的政策評估 ## IAM 角色的政策評估 下列流程圖詳細說明如何針對單一帳戶內的 IAM 角色作出政策評估決策。 ![\[單一帳戶內 IAM 角色的評估流程圖\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png) ## IAM 使用者的政策評估 下列流程圖詳細說明如何針對單一帳戶內的 IAM 使用者作出政策評估決策。 ![\[單一帳戶內 IAM 使用者的評估流程圖\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png) ## 以身分為基礎和以資源為基礎的政策的範例 最常見的政策類型是以身分為基礎的政策和以資源為基礎的政策。請求存取資源時， 會針對同一帳戶內**至少一個允許** AWS ，評估政策授予的所有許可。所有政策中的明確拒絕都會覆寫該允許。 **重要** 如果在相同帳戶中，身分型政策和資源型政策中的任意一項政策允許請求而另一項不允許，則請求仍將被允許。 假設 Carlos 有使用者名稱 `carlossalazar`，他嘗試儲存檔案到 `amzn-s3-demo-bucket-carlossalazar-logs` Amazon S3 儲存貯體。 另外，也假設以下政策已連接到 `carlossalazar` IAM 使用者。 ------ #### [ JSON ] **** ``` { "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` 儲存貯體。 ------ #### [ JSON ] **** ``` { "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 會決定哪些政策適用於請求。在這種情況下，只有以身分為基礎的政策和以資源為基礎的政策適用。這兩者都是許可政策。由於未套用許可界限，評估邏輯會降低到以下邏輯。 ![\[評估流程圖\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/EffectivePermissionsShort.png) AWS 會先檢查套用到請求內容的`Deny`陳述式。它找到一個，因為以身分為基礎的政策明確拒絕 Carlos 存取任何用於記錄的 S3 儲存貯體。Carlos 存取遭拒。 假設他發現自己的錯誤，並嘗試將檔案儲存到儲存`amzn-s3-demo-bucket-carlossalazar`貯體。 AWS 檢查是否有`Deny`陳述式，但找不到。接著檢查許可政策。身分類型政策和資源類型政策都允許請求。因此， AWS 允許請求。如果其中一個元素明確拒絕陳述式、請求會被拒絕。如果其中一種政策類型允許請求，但另一種則不允許，則仍會允許請求。 # 跨帳戶政策評估邏輯 您可以允許一個帳戶中的主體存取第二個帳戶中的資源。這稱為跨帳戶存取。當您允許跨帳戶存取時，主體所在的帳戶稱為*受信任*帳戶。資源所在的帳戶是*信任*帳戶。 若要允許跨帳戶存取，請將以資源為基礎的政策連接至您要共用的資源。您也必須將身分型政策連接至在請求中扮演主體的身分。信任帳戶中的資源型政策，必須指定具有資源存取權的受信任帳戶主體。您可以指定整個帳戶或其 IAM 使用者、 AWS STS 聯合身分使用者主體、IAM 角色或擔任角色的工作階段。您也可以將 AWS 服務指定為委託人。如需詳細資訊，請參閱[如何指定主體](reference_policies_elements_principal.md#Principal_specifying)。 主體的以身分為基礎的政策，必須允許要求存取信任服務中的資源。可以指定資源的 ARN 來執行此操作。 在 IAM 中，您可以將以資源為基礎的政策連接至 IAM 角色，以允許其他帳戶中的主體擔任該角色。角色的以資源為基礎的政策稱為角色信任政策。擔任該角色之後，允許的主體可以使用產生的臨時憑證，以存取您帳戶中的多個資源。此存取是在角色的以身分為基礎的許可政策中定義。若要了解使用角色允許跨帳戶存取，與使用其他以資源為基礎的政策允許跨帳戶存取有何不同，請參閱 [IAM 中的跨帳戶資源存取](access_policies-cross-account-resource-access.md)。 **重要** 其他服務會影響政策評估邏輯。例如， AWS Organizations 支援可套用至一或多個帳戶中主體和資源[的服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)[和資源控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。 AWS Resource Access Manager 支援政策片段，以控制允許主體對與其共用的資源執行哪些動作。 [https://docs.aws.amazon.com/ram/latest/userguide/permissions.html](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html) ## 決定是否允許跨帳戶請求 對於跨帳戶請求，受信任 `AccountA` 中的請求者必須具有以身分為基礎的政策。該政策必須允許他們對信任 `AccountB` 中的資源提出請求。此外，`AccountB` 中以資源為基礎的政策，必須允許 `AccountA` 中的請求者存取資源。 當您提出跨帳戶請求時， 會 AWS 執行兩項評估。 會 AWS 評估信任帳戶和信任帳戶中的請求。如需有關如何在單一帳戶內評估請求的詳細資訊，請參閱 [AWS 強制執行程式碼邏輯如何評估允許或拒絕存取的請求](reference_policies_evaluation-logic_policy-eval-denyallow.md)。只有當兩項評估都傳回 `Allow` 決定時，才允許此請求。 ![\[跨帳戶評估\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png) 1. 當一個帳戶中的主體請求存取另一個帳戶中的資源時，就稱為跨帳戶請求。 1. 提出請求的主體存在於受信任帳戶中 (`AccountA`)。 AWS 評估此帳戶時會檢查以身分為基礎的政策，以及可限制以身分為基礎的政策的任何政策。如需詳細資訊，請參閱[搭配許可界限來評估以身分為基礎的政策](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound)。 1. 所請求的資源存在於信任帳戶中 (`AccountB`)。 AWS 評估此帳戶時會檢查連接至所請求資源的以資源為基礎的政策，以及可限制以資源為基礎的政策的任何政策。如需詳細資訊，請參閱[搭配以資源為基礎的政策來評估以身分為基礎的政策](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp)。 1. AWS 只有在兩個帳戶政策評估都允許請求時， 才會允許請求。 下列流程圖更詳細地說明如何針對跨帳戶請求作出政策評估決策。同樣地，只有在兩個帳戶政策評估都 AWS 允許請求時， 才會允許請求。 ![\[詳細的跨帳戶政策評估\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png) ## 跨帳戶政策評估範例 下列範例示範一個帳戶中的角色由第二個帳戶中資源型政策授予許可的案例。 假設 Carlos 是開發人員，而且他在帳戶 111111111111 中是名為 `Demo` 的 IAM 角色。他想將檔案儲存至帳戶 222222222222 中的 `amzn-s3-demo-bucket-production-logs` Amazon S3 儲存貯體。 另外，也假設以下政策已連接到 `Demo` IAM 角色。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "AllowS3ProductionObjectActions", "Effect": "Allow", "Action": "s3:*Object*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*log*", "arn:aws:s3:::*log*/*" ] } ] } ``` ------ 此政策中的 `AllowS3ListRead` 陳述式允許 Carlos 檢視 Amazon S3 中所有儲存貯體的清單。`AllowS3ProductionObjectActions` 陳述式允許 Carlos 完整存取 `amzn-s3-demo-bucket-production` 儲存貯體中的物件。 此外，以下以資源為基礎的政策 (稱為儲存貯體政策) 已連接至帳戶 222222222222 中的 `amzn-s3-demo-bucket-production` 儲存貯體。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject*", "s3:ReplicateObject", "s3:RestoreObject" ], "Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" }, "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" } ] } ``` ------ 此政策允許 `Demo` 角色存取 `amzn-s3-demo-bucket-production` 儲存貯體中的物件。角色可建立與編輯儲存貯體中的物件，但不能刪除。角色無法管理儲存貯體本身。 當 Carlos 提出將檔案儲存至儲存`amzn-s3-demo-bucket-production-logs`貯體的請求時， AWS 會決定哪些政策適用於請求。在此情況下，連接至 `Demo` 角色的身分型政策是帳戶 `111111111111` 中唯一套用的政策。在帳戶 `222222222222` 中，沒有任何以資源為基礎的政策連接至 `amzn-s3-demo-bucket-production-logs` 儲存貯體。當 AWS 評估帳戶 時`111111111111`，會傳回 的決策`Deny`。這是因為以身分為基礎的政策中的 `DenyS3Logs` 陳述式，明確拒絕存取任何日誌儲存貯體。如需有關如何在單一帳戶內評估請求的詳細資訊，請參閱 [AWS 強制執行程式碼邏輯如何評估允許或拒絕存取的請求](reference_policies_evaluation-logic_policy-eval-denyallow.md)。 因為其中一個帳戶內明確拒絕請求，所以最終決定是拒絕請求。 ![\[針對 amzn-s3-demo-bucket-production-logs 儲存貯體的請求\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png) 假設 Carlos 接著發現他的錯誤，並嘗試將檔案儲存至 `Production`儲存貯體。 AWS 首先 會檢查帳戶`111111111111`，以判斷是否允許請求。只有身分型政策適用，且允許 request. AWS then 檢查帳戶 `222222222222`。只有連接至 `Production` 儲存貯體的以資源為基礎的政策才會套用，並允許請求。因為這兩個帳戶都允許請求，所以最終決定是允許請求。 ![\[對 Production 儲存貯體的請求\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png)