學習阿里雲的訪問控制

我們使用訪問控制策略來描述如何保護系統中的資源, 准許執行哪些操作, 禁止執行哪些操作. 本文從常見的訪問控制策略入手, 逐步瞭解阿里雲平臺的訪問控制策略表達方法.

常見的訪問控制

不同的系統, 根據系統所管理的資源及所支援的操作的特性, 採取了不同的訪問控制策略.

Linux檔案訪問控制

熟悉Linux的朋友都知道檔案的訪問控制，可以給使用者、組及其他使用者不同的讀、寫、執行許可權。

$ ls -l

total 0

-rw-r--r--  1 gang  wheel  0 May 18 08:47 file1.txt

-rw-r--r--  1 gang  wheel  0 May 18 08:47 file2.txt

-rwxr-xr-x  1 gang  wheel  0 May 18 08:47 file3.sh

-rwxr--r--  1 gang  wheel  0 May 18 08:47 file4

對file1.txt和file2.txt，使用者gang 有讀寫許可權；其他使用者有隻讀許可權；

對file3.sh，使用者gang有讀寫和執行許可權；其他使用者有讀和執行的許可權；

對於file4，使用者gang有讀寫和執行許可權；其他使用者有隻讀許可權。

SQL資料庫訪問控制

熟悉SQL的朋友都知道資料庫的訪問控制，可以給不同的資料庫物件以不同的操作許可權。

GRANT SELECT, INSERT, UPDATE, DELETE on <DB>.<TABLE> to <User>@<Host>;

上述語句授予了來自Host的使用者User，對於資料庫DB中的表Table的增刪改查操作許可權。

雲平臺訪問控制

相比單個檔案系統和單個資料庫，雲平臺中的資源有以下特徵

1. 資源分散在不同區域的資料中心中。
2. 資源種類更多。比如ECS虛擬機器，RDB資料庫，NoSQL資料庫，FaaS等。
3. 不同型別的資源，可以執行的操作不同。

第一個特徵和第二個決定了我們在定位資源時，要比Linux檔案系統及資料庫表更復雜。從邏輯上來說，應該包括區域，服務型別，租戶和服務例項。包含租戶，是因為雲平臺都是多租戶隔離的，服務例項執行在租戶（邏輯上）隔離的環境中。
第三個特徵決定了我們在授予使用者操作許可權時，可授權的操作是由服務型別決定的。

假如我們有以下的授權需求：
“允許租戶A(TenantA)的使用者User1重啟(Reboot)該租戶位於北京區域(cn-beijing)的ECS例項Instance-01”

如果用類似SQL的語法來表達如下：

GRANT ECS_Reboot on `cn-beijing`.`ECS`.`TenantA`.`Instance-01` to `User1`@`TenantA`

雲平臺的訪問控制服務所採納的語法是基於JSON格式的. JSON格式對於網際網路開發者而言更常用 — 絕大部分的網際網路API的請求和響應格式都是JSON.

我們把上述SQL格式的授權, 翻譯為JSON格式的:

{
"Resources": ["`cn-beijing`.`ECS`.`TenantA`.`Instance-01`" ],
"Actions": [ "ECS_Reboot"],
"Users": ["User1@TenantA"]
}

一方面, 同樣的訪問控制策略, 既可以賦給使用者A, 也可以賦給使用者B;  另一方面, 使用者A可能的許可權可能同時由多個訪問控制策略所共同決定. 因此, 我們應該把訪問控制策略獨立出來.

訪問控制策略:

{
"Id": "Policy-1",
"Resources": ["cn-beijing.ECS.TenantA.Instance-01" ], 
"Actions": [ "ECS_Reboot"]
},
{
"Id": "Policy-2",
"Resources": ["cn-shanghai.OSS.TenantA.MyFiles"],
"Actions": ["OSS_View", "OSS_Create"]
}

我們稱使用者被授予訪問控制策略的過程叫做使用者與訪問控制策略的繫結.

{
"Binding": {
   "User": "User1@TenantA",
   "Policies": ["Policy-1", "Policy-2"]
}
}

本文的重點是訪問控制策略. 因此, 讓我們把繫結的事情先放一放.

首先, 我們上面只說了正向的”准許”的訪問許可權, 那麼我們能不能反向”拒絕”呢? 假設某個服務例項S的大部分操作, 我們都想賦給使用者U, 只有很少的操作(X, Y)不能給他(她). 這種情況下, 與其列出准許的操作, 不如列出拒絕的操作.

{
 "Id": "Policy-3",
"Statements": [
  { 
    "Effect": "Allow",
    "Resources" : ["S"],
    "Actions" : [ "*" ]
  },
  { 
    "Effect": "Deny",
    "Resources": ["S"],
    "Actions": ["X", "Y"]
  } 
]
}

由於預設情況下是沒有授權的, 因此, 我們需要增加一個表示允許全部授權的規則, 然後再加上拒絕的規則. 這也意味著, “拒絕”規則的效力是高於”准許”規則的. 由於我們申明有了兩(多)個規則, 因此, 增加一個”Statements”陣列來表達它們.

其次, 作為一個平臺, 我們將來可能會引入更多的策略表達能力, 因此, 我們需要引入策略規則版本的概念.

{
 "Id": "Policy-3",
 "Version": "1.0",
"Statements": [
  { 
    "Effect": "Allow",
    "Resources" : ["S"],
    "Actions" : [ "*" ]
  },
  { 
    "Effect": "Deny",
    "Resources": ["S"],
    "Actions": ["X", "Y"]
  } 
]
}

阿里雲平臺的訪問控制

讓我們拿一個真正的阿里雲訪問控制策略的例子來對比一下上面我們自己假想的訪問控制策略.

{
"Version": "1", 
"Statement": [
  { 
    "Effect": "Allow",
    "Resource" : ["acs:ecs:*:*:instance/inst-001", 
"acs:ecs:*:*:instance/inst-002"],
    "Action" : [ "ecs:*" ]
  },
  { 
    "Effect": "Deny",
    "Resource": ["acs:ecs:*:*:instance/inst-001",
"acs:ecs:*:*:instance/inst-002"],
    "Action": ["ecs:Delete*", "ecs:Modify*", "ecs:Re*"]
  } 
]
}

差別在哪裡?

1. 阿里雲採用了單數表達法.  我們前面使用的是”Statements”, “Resources”, “Actions”, 在阿里雲中實際上是”Statement”, “Resource”, “Action”.
2. 阿里雲中的全域性資源名稱中,各個部分之間的分隔符是冒號”:”而不是點”.”, 而且統一使用了小寫的名稱, 它的一般寫法是"acs:<service-name>:<region>:<account>:<instance>". 其中, acs代表阿里雲; service-name代表阿里雲所提供的雲服務的名字(英文程式碼), region表示資料中心區域(英文程式碼); account代表我們的賬號ID; instance代表服務例項的ID.
3. 服務的全域性操作名稱也是使用了冒號來分割服務名稱和操作名稱, 它的一般寫法是"<service-name>:<API name>|<API name starts with (*) >"
4. 參考阿里雲的幫助文件, 我們可以發現阿里雲的訪問策略語法功能更豐富.

練習

設想以下場景：

我們團隊有兩個專案P1和P2，專案人員有產品工程師，開發工程師，測試工程師，運維工程師。其中專案的產品工程師是隻負責各自的專案，開發工程師，測試工程師和運維工程師則同時參與兩個專案中。我們為每個專案分別申請了一臺測試機器，兩臺生產機器以及一個測試RDB資料庫和一個高可用生產RDB資料庫。測試環境的機器，開發工程師和開發工程師都可以檢視和重啟。生產環境的機器，只有運維工程師可以檢視和重啟。產品工程師只能檢視所負責專案. 這個需求怎麼用阿里雲的訪問控制策略實現?

專案P1:

P1-Test-App1, 用於測試環境的應用程式節點
P1-Test-RDB1, 用於測試環境的RDB資料庫
P1-Prod-App1, P1-Prod-App2 用於生產環境的應用程式節點
P1-Prod-RDB1 用於生產環境的高可用版本的RDB資料庫
專案P2:

P2-Test-App1, 用於測試環境的應用程式節點
P2-Test-RDB1, 用於測試環境的RDB資料庫
P2-Prod-App1, P2-Prod-App2 用於生產環境的應用程式節點
P2-Prod-RDB1 用於生產環境的高可用版本的RDB資料庫

參考文件

阿里雲訪問控制策略. 語法結構: https://help.aliyun.com/document_detail/28664.html; 基本元素: https://help.aliyun.com/document_detail/28663.html;  許可權規則: https://help.aliyun.com/document_detail/28665.html
阿里雲ECS鑑權: https://help.aliyun.com/document_detail/25494.html
阿里雲RDB鑑權: https://help.aliyun.com/document_detail/26307.html