權限原則判定流程 - Resource Access Management

當RAM身份（RAM使用者或RAM角色）通過阿里雲控制台、API或CLI發起資源訪問請求時，都需要執行權限原則的判定流程，根據判定結果決定是否允許訪問。本文為您介紹阿里雲的權限原則判定流程。

概述

阿里雲支援多種類型的權限原則。一次完整的權限原則判定流程包含以下步驟：

判定程式收集訪問請求涉及的所有類型的權限原則，包括：資來源目錄的管控策略（Control Policy）、RAM角色的會話策略（Session Policy）、基於身份的策略（Identity-based Policy）和基於資源的策略（Resource-based Policy）。
判定程式會按照最小單元判定流程依次對每一種權限原則執行判定，根據判定結果決定是否繼續進行下一步判定，直到判定結束並獲得最終的判定結果。

最小單元判定流程

每種類型的權限原則都會按照下圖所示的流程進行許可權判定，這個流程稱為最小單元判定流程。

權限原則內部判定規則

最小單元判定流程如下：

許可權判定遵循Deny優先原則，優先檢查訪問請求是否命中Deny語句。
- 是：判定結束，返回判定結果為Explicit Deny（顯式拒絕）。
- 否：繼續下一步判定。
檢查訪問請求是否命中Allow語句。
- 是：判定結束，返回判定結果為Allow（允許）。
- 否：判定結束，返回判定結果為Implicit Deny（隱式拒絕）。

判定結果說明如下表所示。

判定結果	說明
Allow（允許）	如果訪問請求命中了權限原則中的Allow語句，且沒有命中Deny語句，那麼本次判定結果是Allow（允許）。
Explicit Deny（顯式拒絕）	一旦訪問請求命中了權限原則中的Deny語句，那麼本次判定結果是Explicit Deny（顯式拒絕）。即使此時訪問請求同時命中了Allow語句，但遵循Deny優先原則，Deny語句優先順序高於Allow語句，判定結果仍為顯式拒絕。
Implicit Deny（隱式拒絕）	如果訪問請求既沒有命中權限原則中的Allow語句，也沒有命中Deny語句，那麼本次判定結果是Implicit Deny（隱式拒絕）。RAM身份預設沒有執行任何操作的許可權，沒有被顯式允許執行的操作都會被隱式拒絕。

完整判定流程

完整的判定流程會按照下圖所示的順序依次對每一種權限原則進行判定，並獲得最終判定結果。

說明

阿里雲的絕大多數雲端服務都按照阿里雲帳號維度進行隔離，只能在單個阿里雲帳號內部執行操作，但也有個別雲端服務（例如：Object Storage Service）允許直接進行跨帳號訪問。無論哪種情況，阿里雲都遵循同樣的許可權判定流程。

權限原則完整判定流程

完整判定流程如下：

管控策略判定
管控策略（Control Policy）是資來源目錄中對成員訪問定義的許可權邊界。如果請求訪問的資源所屬帳號是資來源目錄的成員，並且管控策略已開啟，判定程式會按照最小單元判定流程執行管控策略判定。否則，判定程式會跳過此步。
根據管控策略的判定結果，作出下一步判定。具體如下：
- 管控策略的判定結果是Explicit Deny（顯式拒絕）或Implicit Deny（隱式拒絕）：判定結束，管控策略的判定結果就是最終的判定結果。
- 管控策略的判定結果是Allow（允許）：繼續進行下一步判定。
重要
管控策略對所有資來源目錄成員中的RAM使用者和RAM角色生效，但對成員的根使用者不生效。同時，資來源目錄的管理帳號位於資來源目錄外部，不歸屬於資來源目錄，所以管控策略對管理帳號內的所有身份也不生效。
會話策略判定
會話策略（Session Policy）是在以編程方式扮演RAM角色（調用AssumeRole API）的過程中建立臨時會話時，在參數中傳遞的策略，用於進一步限制會話的許可權。如果發起訪問請求的身份是RAM角色，並且擁有會話策略，判定程式會按照最小單元判定流程執行會話策略判定。否則，判定程式會跳過此步。
根據會話策略的判定結果，作出下一步判定。具體如下：
- 會話策略的判定結果是Explicit Deny（顯式拒絕）或Implicit Deny（隱式拒絕）：判定結束，會話策略的判定結果就是最終的判定結果。
- 會話策略的判定結果是Allow（允許）：繼續進行下一步判定。
基於身份的策略判定和基於資源的策略判定
同時進行基於身份的策略（Identity-based Policy）判定和基於資源的策略（Resource-based Policy）判定，並將兩者的判定結果緩衝。
- 基於身份的策略判定
  對於RAM使用者，基於身份的策略包括直接授權的策略和從RAM使用者組中繼承的策略。對於RAM角色，基於身份的策略為直接授權的策略。基於身份的策略因授權範圍不同，又分為帳號層級和資源群組層級，帳號層級的策略優先順序高於資源群組層級的策略。
  判定流程如下：
  1. 檢查發起訪問請求的RAM身份是否擁有帳號層級的基於身份的策略。
    是：判定程式按照最小單元判定流程執行帳號層級的身份策略判定。判定結果說明如下：
    如果判定結果是Explicit Deny（顯式拒絕）或Allow（允許）：基於身份策略的判定結束，將結果緩衝到判定結果A。
    如果判定結果是Implicit Deny（隱式拒絕）：繼續進行下一步判定。
    否：繼續進行下一步判定。
  2. 檢查發起訪問請求的RAM身份是否擁有資源群組層級的基於身份的策略。
    是：判定程式按照最小單元判定流程執行資源組層級的身份策略判定，並將結果緩衝到判定結果A。
    否：直接儲存判定結果A為Implicit Deny（隱式拒絕）。
- 基於資源的策略判定
  檢查請求訪問的資源是否擁有基於資源的策略。
  - 是：判定程式按照最小單元判定流程執行基於資源的策略判定，並將結果緩衝到判定結果B。
  - 否：直接儲存判定結果B為Implicit Deny（隱式拒絕）。
  說明
  目前阿里雲提供了兩種基於資源的策略：OSS儲存空間策略（Bucket Policy）和RAM角色的信任策略（Trust Policy）。如果請求訪問的不是以上兩種資源，則不會進行基於資源的策略判定，而直接將基於身份的策略判定結果作為最終結果。
合并判定結果
將基於身份策略的判定結果A和基於資源策略的判定結果B進行合并。合并邏輯如下：
- 如果判定結果A和判定結果B中存在任意一個Explicit Deny（顯式拒絕）：合并後的最終判定結果為Explicit Deny（顯式拒絕），判定結束。
- 如果判定結果A和判定結果B中存在任意一個Allow（允許）：合并後的最終判定結果為Allow（允許），判定結束。
- 如果判定結果A和B中既無Explicit Deny（顯式拒絕）也無Allow（允許）：合并後的最終判定結果為Implicit Deny（隱式拒絕），判定結束。
說明
- 合并判定結果的邏輯由資源所屬的雲端服務決定，也可能存在上述以外的情況。例如：扮演RAM角色時的權限原則判定流程。
- OSS的許可權判定，在合并判定結果之後還需要繼續進行Bucket或Object ACL相關判定。OSS的完整許可權判定流程，請參見OSS鑒權詳解。
如果最終判定結果是Allow（允許），訪問會被允許。不管最終判定結果是Explicit Deny（顯式拒絕）還是Implicit Deny（隱式拒絕），訪問均會被拒絕。