存取控制 - Object Storage Service

發送訪問OSS的請求

您可以直接使用OSS提供的RESTful API介面訪問或者使用對API介面進行完整封裝的SDK開發包。而每一次向OSS的請求根據當前Bucket許可權和操作不同要求使用者進行身分識別驗證或者直接匿名訪問。對OSS的資源訪問的分類如下：

按訪問者的角色可分為擁有者訪問和第三方使用者訪問。這裡的擁有者指的是Bucket的Owner，也稱為開發人員。第三方使用者是指訪問Bucket裡資源的使用者。
按訪問者的身份資訊可分為匿名訪問和帶簽名訪問。對於OSS來說，如果請求中沒有攜帶任何和身份相關的資訊即為匿名訪問。帶簽名訪問指的是按照OSS API文檔中規定的在要求標頭部或者在請求URL中攜帶簽名的相關資訊。

AccessKey 類型

目前訪問 OSS 使用的 AK（AccessKey）有三種類型，具體如下：

阿里雲帳號AccessKey
阿里雲帳號AK特指Bucket擁有者的AK，每個阿里雲帳號提供的AccessKey對擁有的資源有完全的許可權。每個阿里雲帳號能夠同時擁有不超過5個active或者inactive的AK對（AccessKeyId和AccessKeySecret）。

使用者可以登入AccessKey管理主控台，申請新增或刪除AK對。

每個AK對都有active/inactive兩種狀態。
- Active 表明使用者的 AK 處於啟用狀態，可以在身分識別驗證的時候使用。
- Inactive 表明使用者的 AK 處於非啟用狀態，不能在身分識別驗證的時候使用。
说明

請避免直接使用阿里雲賬戶的 AccessKey。
RAM子帳號AccessKey
RAM (Resource Access Management) 是阿里雲提供的資源存取控制服務。RAM帳號AK指的是通過RAM被授權的AK。這組AK只能按照RAM定義的規則去訪問Bucket裡的資源。通過RAM，您可以集中管理您的使用者（比如員工、系統或應用程式），以及控制使用者可以訪問您名下哪些資源的許可權。比如能夠限制您的使用者只擁有對某一個Bucket的讀許可權。子帳號是從屬於主帳號的，並且這些帳號下不能擁有實際的任何資源，所有資源都屬於主帳號。
STS帳號AccessKey
STS（Security Token Service）是阿里雲提供的臨時訪問憑證服務。STS帳號AK指的是通過STS頒發的AK。這組AK只能按照STS定義的規則去訪問Bucket裡的資源。

身分識別驗證具體實現

目前主要有三種身分識別驗證方式：

AK驗證
RAM驗證
STS驗證

當使用者以個人身份向OSS發送請求時，其身分識別驗證的實現如下：

使用者將發送的請求按照OSS指定的格式生成簽名字元串。
使用者使用AccessKeySecret對簽名字元串進行加密產生驗證碼。
OSS收到請求以後，通過AccessKeyId找到對應的AccessKeySecret，以同樣的方法提取簽名字元串和驗證碼。
- 如果計算出來的驗證碼和提供的一樣即認為該請求是有效。
- 否則，OSS將拒絕處理這次請求，並返回HTTP 403錯誤。

對於使用者來說可以直接使用OSS提供的SDK，配合不同類型的AccessKey即可實現不同的身分識別驗證。

許可權控制

針對存放在Bucket的Object的訪問，OSS提供了多種許可權控制，主要有：

Bucket等級許可權
Object等級許可權
帳號等級許可權（RAM）
臨時帳號許可權（STS）

Bucket等級許可權

Bucket權限類別型

OSS提供ACL（Access Control List）許可權控制方法，OSS ACL提供Bucket等級的許可權存取控制，Bucket目前有三種存取權限：public-read-write，public-read和private，它們的含義如下：


許可權值	中文名稱	許可權對訪問者的限制
public-read-write	公共讀寫	任何人（包括匿名訪問）都可以對該Bucket中的Object進行讀/寫/刪除操作；所有這些操作產生的費用由該Bucket的Owner承擔，請慎用該許可權。
public-read	公共讀，私有寫	只有該Bucket的Owner或者授權對象可以對存放在其中的Object進行寫/刪除操作；任何人（包括匿名訪問）可以對Object進行讀操作。
private	私有讀寫	只有該Bucket的Owner或者授權對象可以對存放在其中的Object進行讀/寫/刪除操作；其他人在未經授權的情況下無法訪問該Bucket內的Object。

Bucket許可權設定和讀取方法
功能使用參考：
- API：Put BucketACL
- SDK：Java SDK-設定Bucket ACL
- 控制台：建立Bucket使用權限設定
- API：Get BucketACL
- SDK：Java SDK-獲取Bucket ACL

Object等級許可權

Object權限類別型

OSS ACL也提供Object等級的許可權存取控制。目前Object有四種存取權限：private, public-read, public-read-write, default。Put Object ACL操作通過Put請求中的“x-oss-object-acl”頭來設定，這個操作只有Bucket Owner有許可權執行。


許可權值	中文名稱	許可權對訪問者的限制
public-read-write	公共讀寫	該ACL表明某個Object是公共讀寫資源，即所有使用者擁有對該Object的讀寫權限。
public-read	公共讀，私有寫	該ACL表明某個Object是公共讀資源，即非Object Owner只有該Object的讀許可權，而Object Owner擁有該Object的讀寫權限。
private	私有讀寫	該ACL表明某個Object是私有資源，即只有該Object的Owner擁有該Object的讀寫權限，其他的使用者沒有許可權操作該Object。
default	預設許可權	該ACL表明某個Object是遵循Bucket讀寫權限的資源，即Bucket是什麼許可權，Object就是什麼許可權。

	说明
	如果沒有設定Object的許可權，即Object的ACL為default，Object的許可權和Bucket許可權一致。如果設定了Object的許可權，Object的許可權大於Bucket許可權。舉個例子，如果設定了Object的許可權是public-read，無論Bucket是什麼許可權，該Object都可以被身分識別驗證訪問和匿名訪問。

Object許可權設定和讀取方法
功能使用參考：
- API：Put Object ACL
- SDK：Java SDK-ObjectACL 中設定Object ACL
- API：Get Object ACL
- SDK：Java SDK-ObjectACL 中讀取Object ACL

帳號等級許可權（RAM）

使用場景
如果您購買了雲資源，您的組織裡有多個使用者需要使用這些雲資源，這些使用者只能共用使用您的雲帳號AccessKey。這裡有兩個問題：
- 您的密鑰由多人共用，泄露的風險很高。
- 您無法控制特定使用者能訪問哪些資源（比如Bucket）的許可權。
解決方法：在您的阿里雲帳號下面，通過RAM可以建立具有自己AccessKey的子使用者。您的阿里雲帳號被稱為主帳號，建立出來的帳號被稱為子帳號，使用子帳號的AccessKey只能使用主帳號授權的操作和資源。
具體實現
有關RAM詳情，請參考RAM使用者手冊。

對於授權中需要的Policy的配置方式可以參考本章最後一節：RAM和STS授權策略（Policy）配置。

臨時帳號許可權（STS）

使用場景
對於您本地身份系統所管理的使用者，比如您的App的使用者、您的企業本地帳號、第三方App，也有直接存取OSS資源的可能，將這部分使用者稱為同盟使用者。此外，使用者還可以是您建立的能訪問您的阿里雲資源的應用程式。

對於這部分同盟使用者，通過阿里雲STS (Security Token Service) 服務為阿里雲帳號（或RAM使用者）提供短期存取權限管理。您不需要透露雲帳號（或RAM使用者）的長期密鑰（如登入密碼、AccessKey），只需要生成一個短期訪問憑證給同盟使用者使用即可。這個憑證的存取權限及有效期間限都可以由您自訂。您不需要關心許可權撤銷問題，訪問憑證過期後會自動失效。

使用者通過STS生成的憑證包括安全性權杖(SecurityToken)、臨時存取金鑰(AccessKeyId, AccessKeySecret)。使用AccessKey方法與您在使用阿里雲賬戶或RAM使用者AccessKey發送請求時的方法相同。此外還需要注意的是在每個向OSS發送的請求中必須攜帶安全性權杖。
具體實現
STS安全性權杖、角色管理和使用相關內容詳情，請參考RAM使用者指南中的角色管理。關鍵是調用STS服務介面AssumeRole來獲取有效訪問憑證即可，也可以直接使用STS SDK來調用該方法。

RAM和STS應用場景實踐

對於不同的應用場景，涉及到的訪問身分識別驗證方式可能存在差異。下面以幾種典型的應用場景來說明訪問身分識別驗證中幾種使用方式。

以一個移動App舉例。假設您是一個移動App開發人員，打算使用阿里雲OSS服務來保存App的終端使用者資料，並且要保證每個App使用者之間的資料隔離，防止一個App使用者獲取到其它App使用者的資料。

方式一：使用AppServer來做資料中轉和資料隔離

如上圖所示，您需要開發一個AppServer。只有AppServer能訪問雲服務，ClientApp的每次讀寫資料都需要通過AppServer，AppServer來保證不同使用者資料的隔離訪問。

對於該種使用方式，使用阿里雲帳號或者RAM帳號提供的密鑰來進行簽名驗證訪問。建議您盡量不要直接使用阿里雲帳號（主帳號）的密鑰訪問OSS，避免出現安全問題。
方式二：使用STS讓使用者直接存取OSS
STS方案描述如下圖所示：

方案的詳細描述如下：
1. App使用者登入。App使用者和雲帳號無關，它是App的終端使用者，AppServer支援App使用者登入。對於每個有效App使用者來說，需要AppServer能定義出每個App使用者的最小存取權限。
2. AppServer請求STS服務獲取一個安全性權杖（SecurityToken）。在調用STS之前，AppServer需要確定App使用者的最小存取權限（用Policy文法描述）以及授權的過期時間。然後通過扮演角色（AssumeRole）來獲取一個代表角色身份的安全性權杖。
3. STS返回給AppServer一個有效訪問憑證，包括一個安全性權杖（SecurityToken）、臨時存取金鑰（AccessKeyId, AccessKeySecret）以及過期時間。
4. AppServer將訪問憑證返回給ClientApp。ClientApp可以緩存這個憑證。當憑證失效時，ClientApp需要向AppServer申請新的有效訪問憑證。比如，訪問憑證有效期間為1小時，那麼ClientApp可以每30分鐘向AppServer請求更新訪問憑證。
5. ClientApp使用本機快取的訪問憑證去請求Aliyun Service API。雲服務會感知STS訪問憑證，並會依賴STS服務來驗證訪問憑證，正確響應使用者請求。

RAM和STS授權策略（Policy）配置

對於RAM或者STS授權中使用Policy，詳細規則如下。

樣本

先看下面的一個Policy樣本：

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "oss:GetBucketAcl",
                "oss:ListObjects"
            ],
            "Resource": [
                "acs:oss:*:1775305056529849:mybucket"
            ],
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "acs:UserAgent": "java-sdk",
                    "oss:Prefix": "foo"
                },
                "IpAddress": {
                    "acs:SourceIp": "192.168.0.1"
                }
            }
        },
        {
            "Action": [
                "oss:PutObject",
                "oss:GetObject",
                "oss:DeleteObject"
            ],
            "Resource": [
                "acs:oss:*:1775305056529849:mybucket/file*"
            ],
            "Effect": "Allow",
            "Condition": {
                "IpAddress": {
                    "acs:SourceIp": "192.168.0.1"
                }
            }
        }
    ]
}

這是一個授權的Policy，使用者用這樣的一個Policy通過RAM或STS服務向其他使用者授權。Policy當中有一個Statement（一條Policy當中可以有多條Statement）。Statement裡面規定了相應的Action、Resource、Effect和Condition。

這條Policy把使用者自己名下的mybucket和mybucket/file*這些資源授權給相應的使用者，並且支援GetBucketAcl、GetBucket、PutObject、GetObject和DeleteObject這幾種操作。Condition中的條件表示UserAgent為java-sdk，源IP為192.168.0.1的時候鑒權才能通過，被授權的使用者才能訪問相關的資源。Prefix這個Condition是在GetBucket（ListObjects）的時候起作用的，關於這個欄位的解釋詳見OSS的API文檔。

配置細則

Version
Version定義了Policy的版本，本文檔中sw2q的配置方式，設定為1。
Statement
通過Statement描述授權語義，其中可以根據業務場景包含多條語義，每條包含對Action、Effect、Resource和Condition的描述。每次請求系統會逐條依次匹配檢查，所有匹配成功的Statement會根據Effect的設定不同分為通過（Allow）、禁止（Deny），其中禁止（Deny）的優先。如果匹配成功的都為通過，該條請求即鑒權通過。如果匹配成功有一條禁止，或者沒有任何條目匹配成功，該條請求被禁止訪問。

Action

Action分為三大類：Service等級操作，對應的是GetService操作，用來列出所有屬於該使用者的Bucket列表。

Bucket等級操作，對應類似於oss:PutBucketAcl、oss:GetBucketLocation之類的操作，操作的對象是Bucket，它們的名稱和相應的介面名稱一一對應。
Object等級操作，分為oss:GetObject、oss:PutObject、oss:DeleteObject和oss:AbortMultipartUpload，操作對象是Object。

如想授權某一類的Object的操作，可以選擇這幾種的一種或幾種。另外，所有的Action前面都必須加上oss:，如上面例子所示。Action是一個列表，可以有多個Action。具體的Action和API介面的對應關係如下：

Service等級


API	Action
GetService（ListBuckets）	oss:ListBuckets

Bucket等級


API	Action
PutBucket	oss:PutBucket
GetBucket（ListObjects）	oss:ListObjects
PutBucketAcl	oss:PutBucketAcl
DeleteBucket	oss:DeleteBucket
GetBucketLocation	oss:GetBucketLocation
GetBucketAcl	oss:GetBucketAcl
GetBucketLogging	oss:GetBucketLogging
PutBucketLogging	oss:PutBucketLogging
DeleteBucketLogging	oss:DeleteBucketLogging
GetBucketWebsite	oss:GetBucketWebsite
PutBucketWebsite	oss:PutBucketWebsite
DeleteBucketWebsite	oss:DeleteBucketWebsite
GetBucketReferer	oss:GetBucketReferer
PutBucketReferer	oss:PutBucketReferer
GetBucketLifecycle	oss:GetBucketLifecycle
PutBucketLifecycle	oss:PutBucketLifecycle
DeleteBucketLifecycle	oss:DeleteBucketLifecycle
ListMultipartUploads	oss:ListMultipartUploads
PutBucketCors	oss:PutBucketCors
GetBucketCors	oss:GetBucketCors
DeleteBucketCors	oss:DeleteBucketCors
PutBucketReplication	oss:PutBucketReplication
GetBucketReplication	oss:GetBucketReplication
DeleteBucketReplication	oss:DeleteBucketReplication
GetBucketReplicationLocation	oss:GetBucketReplicationLocation
GetBucketReplicationProgress	oss:GetBucketReplicationProgress

Object等級


API	Action
GetObject	oss:GetObject
HeadObject	oss:GetObject
PutObject	oss:PutObject
PostObject	oss:PutObject
InitiateMultipartUpload	oss:PutObject
UploadPart	oss:PutObject
CompleteMultipart	oss:PutObject
DeleteObject	oss:DeleteObject
DeleteMultipartObjects	oss:DeleteObject
AbortMultipartUpload	oss:AbortMultipartUpload
ListParts	oss:ListParts
CopyObject	oss:GetObject,oss:PutObject
UploadPartCopy	oss:GetObject,oss:PutObject
AppendObject	oss:PutObject
GetObjectAcl	oss:GetObjectAcl
PutObjectAcl	oss:PutObjectAcl

Resource
Resource指代的是OSS上面的某個具體的資源或者某些資源（支援*通配），resource的規則是acs:oss:{region}:{bucket_owner}:{bucket_name}/{object_name}。對於所有Bucket等級的操作來說不需要最後的斜杠和{object_name}，即acs:oss:{region}:{bucket_owner}:{bucket_name}。Resource也是一個列表，可以有多個Resource。其中的region欄位暫時不做支援，設定為*。

Effect

Effect代表本條的Statement的授權的結果，分為Allow和Deny，分別指代通過和禁止。多條Statement同時匹配成功時，禁止（Deny）的優先順序更高。

例如，期望禁止使用者對某一目錄進行刪除，但對於其他檔案有全部許可權：

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:*"
      ],
      "Resource": [
        "acs:oss:*:*:bucketname"
      ]
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteObject"
      ],
      "Resource": [
        "acs:oss:*:*:bucketname/index/*",
      ]
    }
  ]
}

Condition

Condition代表Policy授權的一些條件，上面的樣本裡面可以設定對於acs:UserAgent的檢查、acs:SourceIp的檢查、還有oss:Prefix這項用來在GetBucket的時候對資源進行限制。

OSS支援的Condition如下：


condition	功能	合法取值
acs:SourceIp	指定ip網段	普通的ip，支援*通配
acs:UserAgent	指定http useragent頭	字元串
acs:CurrentTime	指定合法的訪問時間	ISO8601格式
acs:SecureTransport	是否是https協議	“true”或者”false”
oss:Prefix	用作ListObjects時的prefix	合法的object name

最佳實務

RAM和STS使用指南

Object Storage Service：存取控制