政策評估邏輯 - AWS Identity and Access Management

政策評估邏輯

當委託人嘗試使用 AWS Management Console、AWS API 或 AWS CLI 時,該委託人會向 AWS 發送請求。當 AWS 服務收到請求時,AWS 會先完成幾個步驟以判斷是否該允許或拒絕請求。

  1. 身分驗證 – AWS 首先驗證提出請求的委託人身分,如有必要。有少數幾個服務並不需要這個步驟,例如 Amazon S3,它允許匿名使用者的一些請求。

  2. 處理請求內容 – AWS 處理請求所收集到的資訊,以判斷將哪些政策套用到請求。

  3. 運用單一帳戶評估政策 – AWS 評估所有政策類型,這會影響評估政策的順序。

  4. 決定是否允許或拒絕帳戶中的請求 – AWS 接著會針對請求內容處理政策,以判斷是否允許或拒絕請求。

處理請求內容

AWS 處理請求以將下列資訊收集到「請求內容」

  • 動作 (或操作) – 委託人想要執行的動作或操作。

  • 資源 – 對其執行動作或操作的 AWS 資源物件。

  • 委託人 – IAM 使用者、角色、聯合身分使用者或傳送請求的應用程式。有關委託人的資訊,包括與該委託人相關聯的政策。

  • 環境資料 – IP 地址、使用者代理程式、啟用 SSL 的狀態或一天中時間的相關資訊。

  • 資源資料 – 與所請求資源相關的資料。這可以包括諸如 DynamoDB 資料表名稱或 Amazon EC2 執行個體上之標籤的資訊。

AWS然後, 使用此資訊尋找適用於請求內容的政策。

運用單一帳戶評估政策

AWS 如何根據套用到請求內容之政策類型來評估政策。下面以頻率順序列出的政策類型,可以提供單一 AWS 帳戶使用。如需有關這些政策類型的詳細資訊,請參閱 IAM 中的政策和許可。若要了解 AWS 如何評估跨帳戶存取的政策,請參閱跨帳戶政策評估邏輯

  1. 以身分為基礎的政策 – 以身分為基礎的政策會連接到 IAM 身分 (使用者、使用者群組或角色),並且授予許可給 IAM 實體 (使用者與角色)。如果只有以身分為基礎的政策套用到請求,則 AWS 至少會為一個 Allow 核取所有的這類政策。

  2. 資源型政策 – 資源型政策會授予許可給指定為委託人的委託人 (帳戶、使用者、角色和工作階段委託人,例如角色工作階段和 IAM 聯合身分使用者)。這些許可會定義委託人可以對政策連接於其中的資源做哪些動作。如果以資源為基礎的政策與以身分為基礎的政策都套用到請求,則 AWS 至少會為一個 Allow 核取所有的這類政策。評估資源型政策時,政策中指定的委託人 ARN 會決定其他政策類型中的隱含拒絕是否適用於最終決定。

  3. IAM 許可界限 – 許可界限是一種進階功能,可負責設定以身分為基礎的政策可以授予 IAM 實體 (使用者或角色) 的最大許可。當您為實體設定許可界限時,實體只能執行由以身分為基礎的政策和其許可界限同時允許的動作。在某些情況下,許可界限中的隱含拒絕會限制資源型政策所授予的許可。如需進一步了解,請參閱本主題稍後的 決定是否允許或拒絕帳戶中的請求

  4. AWS Organizations 服務控制政策 (SCP) – Organizations SCP 會指定組織或組織單位 (OU) 的最大許可。SCP 最大許可會套用到成員帳戶中的委託人,包括每個 AWS 帳戶 根使用者。如果 SCP 存在,則只有在這些政策和 SCP 允許該動作執行時,以身分為基礎和以資源為基礎的政策才會對成員帳戶中的委託人授予許可。如果許可界限和 SCP 兩者都存在,則此界限、SCP 和以身分為基礎的政策都必須允許該動作。

  5. 工作階段政策 – 工作階段政策是一種進階政策,您可以在透過編寫程式的方式建立角色或聯合身分使用者的暫時工作階段時,作為參數傳遞。若要以程式設計方式建立角色工作階段,請使用其中一種 AssumeRole* API 操作。當您這麼做且傳遞工作階段政策時,所產生工作階段的許可會是 IAM 實體的身分類型政策和工作階段政策的交集。若要建立聯合身分使用者工作階段,您要使用 IAM 使用者存取金鑰,以程式設計的方式來呼叫 GetFederationToken API 操作。以資源為基礎的政策對工作階段政策許可的評估會有不同的效果。效果差異會因使用者或角色的 ARN 或工作階段的 ARN 是否在以資源為基礎的政策中列為委託人而有所不同。如需詳細資訊,請參閱 工作階段政策

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

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

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


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

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

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


          評估以身分為基礎的政策及許可界限

搭配 Organizations SCP 來評估以身分為基礎的政策

當使用者所屬的帳戶是組織的成員,產生的許可會是使用者政策和 SCP 的交集。這就代表該動作必須同時獲得以身分為基礎的政策和 SCP 的允許。在這些政策的明確拒絕會覆寫允許。


          評估以身分為基礎的政策和 SCP

您可以了解您的帳戶是否為 AWS Organizations 中組織的成員。組織成員可能會受到 SCP 影響。若要使用 AWS CLI 命令或 AWS API 操作檢視此資料,您必須擁有適用於 Organizations 實體的 organizations:DescribeOrganization 動作許可。您必須擁有其他許可,才能在 Organizations 主控台中執行操作。若要了解 SCP 是否拒絕存取特定要求,或是變更有效的許可,請聯絡您的 AWS Organizations 管理員。

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

假設委託人將請求傳送到 AWS 來在與委託人實體相同的帳戶中存取資源。AWS 強制執行程式碼會決定是否應允許或拒絕該請求。AWS 會評估適用於請求內容的所有政策。以下是適用於單一帳戶內存政策的 AWS 評估邏輯的摘要。

  • 根據預設,所有的要求一律拒絕,AWS 帳戶 根使用者提出的要求例外,該使用者具有完整存取權。

  • 若是以身分為基礎或以資源為基礎的政策,當中的明確允許會覆寫此預設值。

  • 如果有許可界限、Organizations SCP 或工作階段政策,則其可能會以隱含拒絕覆寫該允許。

  • 任何政策中的明確拒絕會覆寫任何允許。

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


        評估流程圖
  1. 拒絕評估 – 根據預設,所有的請求一律拒絕。這稱為隱含拒絕。AWS 強制執行程式碼會在帳戶內評估所有套用到請求的政策。這些政策包括 AWS Organizations SCP、資源型政策、身份型政策、IAM 許可界限和工作階段政策。在所有這些政策中,強制執行程式碼會尋找套用到請求的 Deny 陳述式。此稱為明確拒絕。如果程式碼找到一個適用的明確拒絕,則程式碼會傳回 拒絕 的最後決定。如果沒有明確拒絕,該程式碼會持續執行。

  2. Organizations SCP – 這段程式碼會接著評估套用到該請求的 AWS Organizations 服務控制政策 (SCP)。SCP 會套用至連接 SCP 的帳戶之委託人。如果強制執行程式碼在 SCP 中找不到任何適用的 Allow 陳述式,請求便是被暗中拒絕。程式碼傳回拒絕的最後決定。如果 SCP 不存在,或是 SCP 允許請求動作,程式碼就會繼續執行。

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

    例如,當資源型政策中指定的委託人是 IAM 使用者、IAM 角色或工作階段委託人時,政策評估會有所不同。工作階段委託人包括 IAM角色工作階段IAM 聯合身分使用者工作階段。如果資源型政策直接將許可授予 IAM 使用者或提出要求的工作階段委託人,則身分識別型政策、許可界限或工作階段政策中的隱含拒絕不會影響最終決定。

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

    資源型政策和其他政策類型 (相同帳戶) 中的隱含拒絕
    委託人發出要求 以資源為基礎政策 身分型政策 許可界限 工作階段政策 結果 原因
    IAM 角色 不適用 不適用 不適用 不適用 不適用 角色本身無法提出要求。擔任角色之後,系統會使用角色工作階段提出要求。
    IAM 角色工作階段 允許角色 ARN 隱含拒絕 隱含拒絕 隱含拒絕 拒絕 許可界限和工作階段政策會作為最終決定的一部分進行評估。任一政策中的隱含拒絕會導致「拒絕」決定。
    IAM 角色工作階段 允許角色工作階段 ARN 隱含拒絕 隱含拒絕 隱含拒絕 允許 許可會直接授予工作階段。其他政策類型不會影響決定。
    IAM 使用者 允許 IAM 使用者 ARN 隱含拒絕 隱含拒絕 不適用 允許 許可直接授予使用者。其他政策類型不會影響決定。
    IAM 聯合身分使用者 (GetFederationToken) 允許 IAM 使用者 ARN 隱含拒絕 隱含拒絕 隱含拒絕 拒絕 許可界限或工作階段政策中的隱含拒絕會導致「拒絕」。
    IAM 聯合身分使用者 (GetFederationToken) 允許 IAM 聯合身分使用者工作階段 ARN 隱含拒絕 隱含拒絕 隱含拒絕 允許 許可會直接授予工作階段。其他政策類型不會影響決定。
    根使用者 允許根使用者 ARN 不適用 不適用 不適用 允許 根帳戶可無限制地全面存取 AWS 帳戶的所有資源。若要了解如何控制對 AWS Organizations 中帳戶的根使用者的存取權,請參閱 Organizations 使用者指南中的服務控制政策 (SCP)
    AWS 服務委託人 允許 AWS 服務委託人 不適用 不適用 不適用 允許 資源型政策直接將許可授予 AWS 服務委託人時,其他政策類型不會影響決定。
    • IAM 角色 – 將許可授予 IAM 角色 ARN 的資源型政策受限於許可界限或工作階段政策中隱含拒絕的限制。

      角色 ARN 範例

      arn:aws:iam::111122223333:role/examplerole
    • IAM 角色工作階段 – 在同一帳戶內,將許可授予 IAM 角色工作階段 ARN 的資源型政策直接授予許可給擔任的角色工作階段。直接授予工作階段的許可不會受到身分識別型政策、許可界限或工作階段政策中隱含拒絕的限制。當您擔任角色並提出要求時,提出要求的委託人是 IAM 角色工作階段 ARN,而不是角色本身的 ARN。

      角色工作階段 ARN 範例

      arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
    • IAM 使用者 – 在同一帳戶內,將許可授予 IAM 使用者 ARN (非聯合身分使用者工作階段) 的資源型政策不受身分識別型政策或許可界限中隱含拒絕的限制。

      IAM 使用者 ARN 範例

      arn:aws:iam::111122223333:user/exampleuser
    • IAM 聯合身分使用者工作階段 – IAM 聯合身分使用者工作階段是透過呼叫 GetFederationToken 建立的工作階段。當聯合身分使用者提出要求時,提出要求的委託人是聯合身分使用者 ARN,而不是聯合身分 IAM 使用者的 ARN。在相同的帳戶中,授予許可給聯合身分使用者 ARN 的資源型政策會直接將許可授予工作階段。直接授予工作階段的許可不會受到身分識別型政策、許可界限或工作階段政策中隱含拒絕的限制。

      但是,如果資源型政策將許可授予聯合身分 IAM 使用者的 ARN,則聯合身分使用者在工作階段期間提出的要求會受到許可界限或工作階段政策中隱含拒絕的限制。

      IAM 聯合身分使用者工作階段 ARN 範例

      arn:aws:sts::111122223333:federated-user/exampleuser
  4. 以身分為基礎的政策 – 程式碼接著會檢查委託人的以身分為基礎的政策。若為 IAM 使用者,這些政策會包含使用者政策,以及使用者所屬群組的政策。如果沒有任何身分型政策或其中的任何陳述式允許該要求動作,則表示要求已遭隱含拒絕,且程式碼會傳回拒絕的最終決定。如果任何適用的身分型政策中有任一陳述式允許該要求動作,則程式碼會繼續執行。

  5. IAM 許可界限 – 程式碼接著會檢查委託人所使用的 IAM 實體是否有許可界限。如果用來設定許可界限的政策不允許該請求動作,則表示請求已遭隱含拒絕。程式碼傳回拒絕的最後決定。如果許可界限不存在,或是許可界限允許請求動作,程式碼就會繼續執行。

  6. 工作階段政策 – 程式碼接著會檢查委託人是否為 工作階段委託人。工作階段委託人包括 IAM 角色工作階段或 IAM 聯合身分使用者工作階段。如果委託人不是工作階段委託人,則強制執行程式碼會傳回允許的最終決定。

    對於工作階段委託人,程式碼檢查工作階段政策是否在要求中傳遞。您可以在使用 AWS CLI 或 AWS API 取得角色或 IAM 聯合身分使用者的暫時憑證時,同時傳遞工作階段政策。

    • 如果工作階段政策存在,且不允許該要求動作,則表示要求已遭隱含拒絕。程式碼傳回拒絕的最後決定。

    • 如果工作階段政策不存在,程式碼會檢查委託人是否為角色工作階段。如果委託人是角色工作階段,則要求為已允許。否則,要求被隱含拒絕,並且程式碼傳回拒絕的最終決定。

    • 如果工作階段政策存在,並允許該要求動作,則強制執行程式碼會傳回允許

  7. 錯誤 – 如果 AWS 強制執行程式碼在評估期間的任何時間點發生錯誤,則會產生例外狀況並關閉。

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

最常見的政策類型是以身分為基礎的政策和以資源為基礎的政策。

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

另外,也假設以下政策已連接到 carlossalazar IAM 使用者。

{ "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:::carlossalazar/*", "arn:aws:s3:::carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::*log*" } ] }

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

此外,以下以資源為基礎的政策 (稱為儲存貯體政策) 已連接到 carlossalazar 儲存貯體。

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

此政策指定只有 carlossalazar 使用者可以存取 carlossalazar 儲存貯體。

當 Carlos 提出請求將檔案儲存到 carlossalazar-logs 儲存貯體時,AWS 會決定套用至請求的政策。在這種情況下,只有以身分為基礎的政策和以資源為基礎的政策適用。這兩者都是許可政策。由於未套用許可界限,評估邏輯會降低到以下邏輯。


        評估流程圖

AWS 會先檢查套用於請求內容的 Deny 陳述式。它找到一個,因為以身分為基礎的政策明確拒絕 Carlos 存取任何用於記錄的 S3 儲存貯體。Carlos 存取遭拒。

假設他了解他的錯誤,嘗試將檔案儲存到 carlossalazar 儲存貯體。AWS 檢查 Deny 陳述式,但找不到。接著檢查許可政策。身分類型政策和資源類型政策都允許請求。因此,AWS 允許請求。如果其中一個元素明確拒絕陳述式、請求會被拒絕。如果其中一種政策類型允許請求,但另一種則不允許,則仍會允許請求。

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

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

如果沒有適用的 Deny 陳述式,也沒有適用的 Allow 陳述式,則會發生暗中拒絕。由於預設拒絕存取 IAM 委託人,他們必須明確獲允許執行動作。否則,會暗中拒絕他們存取。

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

例如,您可以建立下列政策,其中包含允許的動作、隱含拒絕的動作以及明確拒絕的動作。此 AllowGetList 陳述式允許對以字首 GetList 開頭的 IAM 動作的唯讀存取。IAM 中的所有其他動作,例如 iam:CreatePolicy,則被隱含拒絕。此 DenyReports 陳述式明確拒絕存取 IAM 報告,方法是拒絕存取包含 Report 尾碼的動作,例如 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": "*" } ] }