OSS鑒權流程詳解 - Object Storage Service

OSS鑒權是驗證請求合法性並判斷是否允許訪問的機制。當使用者發起訪問請求時，OSS根據請求類型、身份資訊和權限原則進行綜合評估，最終決定允許或拒絕該請求。

工作原理

請求類型

OSS根據請求是否攜帶身份資訊，將訪問請求分為兩類：

請求類型	說明
非匿名請求	在要求標頭部或URL中攜帶簽名等身份相關資訊。
匿名請求	在要求標頭部或URL中未攜帶任何身份相關資訊。

鑒權原則

OSS鑒權遵循顯式拒絕優先原則，按以下優先順序順序判斷請求：

Explicit Deny（最高優先順序）：匹配到Deny規則時，請求立即被拒絕。
Allow：無Deny規則匹配時，若匹配到Allow規則，請求被允許。
Implicit Deny（預設）：無任何規則匹配時，請求預設被拒絕。

非匿名請求鑒權流程

非匿名請求需要經過身分識別驗證、會話策略、RAM Policy、Bucket Policy、ACL等多層鑒權。

鑒權流程具體步驟如下：

身分識別驗證：OSS將請求攜帶的簽名與服務端計算的簽名進行比對驗證。
- 不匹配：拒絕訪問。
- 匹配：繼續下一步。
檢查Session Policy：判斷當前請求是否為基於角色的會話策略。
- 是：檢查Session Policy，若為Explicit Deny或Implicit Deny則拒絕訪問，Allow則繼續執行。
- 否：跳過此步驟繼續執行。
檢查RAM Policy和Bucket Policy：分別檢查兩種策略併合並結果。
- RAM Policy：基於身份的策略，控制RAM使用者可訪問的資源。對於使用者層級的訪問，需根據請求的帳號類別判斷：
  - 阿里雲帳號AccessKey：直接返回Implicit Deny。
  - RAM使用者AccessKey或STS AccessKey：Bucket不屬於該阿里雲帳號或RAM角色Owner時，直接返回Implicit Deny；否則由RAM服務進行鑒權，返回Allow、Explicit Deny或Implicit Deny。
- Bucket Policy：基於資源的策略，控制Bucket或其內資源的存取權限。
  - 未設定策略：直接返回Implicit Deny。
  - 已設定策略：返回Allow、Explicit Deny或Implicit Deny。
檢查合并結果：根據RAM Policy和Bucket Policy的檢查結果進行綜合判斷。
- 存在Explicit Deny：拒絕訪問。
- 存在Allow：允許訪問。
- 均為Implicit Deny：繼續下一步。
判斷請求介面來源：根據API介面類型決定後續處理。
- 管控類API（如GetService、PutBucket、PutLiveChannel等）：拒絕訪問。
- 資料類API（如PutObject、GetObject等）：繼續檢查ACL。
檢查Object ACL和Bucket ACL：根據檢查結果允許或拒絕訪問。
- 檢查Object ACL時，需結合請求使用者是否為Bucket Owner以及請求類型（讀請求或寫請求）進行判斷。
- 若Object ACL為繼承Bucket，則繼續檢查Bucket ACL。檢查Bucket ACL時，同樣需結合請求使用者是否為Bucket Owner進行判斷。

匿名請求鑒權流程

匿名請求跳過身分識別驗證和RAM Policy檢查，僅根據Bucket Policy和ACL進行鑒權。