對雲環境下訪問控制系統的思考
本文由 網易雲 發布。
企業上雲首當其沖的就是要考量安全性的問題。安全性範圍很廣，狹義上可以指雲服務商的各種安全服務，如 DDoS 防護、其他安全性產品等，而廣義上來說，安全性不僅包括基礎設施的安全和穩定，如虛擬機的高可用、RDS 的高可靠等，也包括應用層面的安全性，如 WAF、證書服務、加密服務等等，還包括了因為企業本身的 IT 架構/研發架構的復雜性帶來的資源管控方面的安全性需求等。可以說，誰解決好企業的安全性訴求，誰就會在雲服務這片紅海中占據很大的優勢。
從廣義上來理解，訪問控制其實是安全中的一塊，也是十分重要的一塊。有些雲計算提供商沒有將其劃歸到安全的範圍，可能是還沒有意識到訪問控制的重要性。
AWS 中訪問控制對應的產品是 IAM，這可以說是雲計算廠商中做的最早也最為完善的一個。AWS 對 IAM 的類別描述裏有一個詞我覺得形容該產品最為合適——“合規性“。其實，訪問控制就是滿足企業用戶對於合規性的需求，說白了就是規範企業用戶對雲計算資源的訪問。
本文就從訪問控制的定義出發，介紹下傳統的訪問控制模型，再針對雲服務場景中訪問控制面臨的特殊挑戰，講解下目前雲服務廠商訪問控制系統的設計原理。
什麽是訪問控制
維基百科關於訪問控制的定義是：
訪問控制是指允許或者禁止某人使用某項資源的能力。
這個定義中有這麽幾個關鍵點：
○ 人
○ 某項資源
○ 允許/禁止
○ 能力
這個定義雖略顯簡單，但其實已勾勒出了訪問控制系統的大致形態。
人：訪問控制的主體是人，代表其主要的使用群體是雲服務商的用戶，即這個系統是一個面向用戶的系統。
某項資源：資源是訪問控制的客體，某項這個限定詞則表明資源的具體形式是未知的。
允許/禁止：這是訪問控制對外提供服務的最為直觀的表現形式，用一個更為專業的名稱來描述的話就是 “鑒權”。
能力：為什麽把能力專門拿出來作為一個關鍵點，是因為這是理論和實踐間一個關鍵的區分點之一。訪問控制的理論為我們設計對應的系統和產品指明了方向，但在實際的生產環境中使用時還是會遇到各種各樣的問題。我們需要特別註意，訪問控制系統作為一個通用的公共服務，它需要提供的是一種能力，而不能僅針對特定環境和產品，否則只是淪為某個特定的專家系統。
維基百科關於【訪問控制】的定義還隱藏了一個關鍵點，那就是 “動作”。這裏的動作（也可稱之為操作）可以理解為具體系統所開放的能力，或者用戶可以對系統執行的操作。例如，RDS 產品需要開放 createDataBase\listDataBase\deleteDatabase 等動作， NOS（網易雲對象存儲）需要開放 listBucket\createBucket\listObject\putObject 等動作等。就算脫離雲計算的環境，動作也是訪問控制中不可缺少的要素之一，因為任何給人使用的產品都會伴隨與人的交互，而這些交互的細粒度表現就是這些動作。
傳統的訪問控制模型
在訪問控制系統的設計中，有兩種設計模式十分重要，也是得到廣泛應用的，那就是訪問控制列表（ACL）和基於角色的訪問控制（RBAC）。
1. 訪問控制列表（ACL）
訪問控制列表是早期的一種訪問控制技術，其原理十分簡單，就是記錄哪些用戶對這個資源能進行哪些操作，有類似如下的二維表維護在文件中：
這種訪問控制的方式好處顯而易見，就是簡單直觀，易維護。這種設計在操作系統、路由器、交換機和工業控制系統中都得到了廣泛的使用。
但是，ACL 的缺點也是顯而易見的，那就是當用戶、資源和操作組建增長時，維護這張表的代價會異常龐大。另外，這種設計模式將用戶對資源的控制權限直接綁定，十分死板，靈活度不夠，無法滿足雲環境下動態資源授權的需求。
2. 基於角色的訪問控制（RBAC）
基於角色的訪問控制將用戶按其屬性進行分類，構建出一個個具體的角色，通過將權限授權角色使不同的用戶獲取相應的權限。RBAC 非常適合現實的業務環境，尤其是企業用戶，其資源的使用者不一定是資源的擁有者。在雲環境中更是如此，可能使用 RDS 的人是公司的開發或者 PE，而 RDS 的歸屬者是對應的企業。
RBAC 從訪問控制的主體的角度出發，很好地適應了企業的組織架構，同時也將用戶和權限分離開，用戶只需要通過扮演不同的角色就能獲得對應的權限，這種方式解決了雲環境下動態授權的權限需求。
那是否 RBAC 就能解決我們所有的問題了？顯然還沒有，現實的問題往往是復雜的。RBAC 將人和權限分離的方法確實解決了一部分靈活性的問題，但是也增加了使用成本，同時它對細粒度的權限控制沒有給出很好的應對之法。
雲服務中訪問控制系統設計需考慮的問題
現在我們知道主流的訪問控制模型一般是怎麽做的了，那麽如何應用在雲環境中呢？我覺得在雲環境下的訪問控制系統主要需要考慮以下幾個問題：
1. 資源標識的靈活性
訪問控制系統的立項一般來講會晚於雲計算中的其他產品，因為它本身屬於支撐產品。而隨著其他產品形態組建完善，如何很好地描述各個產品的資源就成了一件令人頭疼的事情。
在一些 IaaS 的產品形態中，很大一部分是以實例 (instance) 的方式來提供服務的；而在某些 PaaS 的產品形態中，有些是實例的方式來提供服務，而又有一些有著很強的特殊性，比如上文提到的 NOS，它們的資源描述是需要以樹形方式來表達的；SaaS 產品用統一的訪問控制系統來管理一般不太可能，因為每個 Software 的產品形態和使用方式千差萬別，你很難去做到統一。
而在對訪問控制系統的設計過程中我也發現了一個很有趣的現象，當你考慮的產品越接近應用層面（上層服務），訪問控制系統就越接近專家系統。也就是說越上層的服務它的特殊性越強，所以通用性越差，只能做成專家系統。
2. 細粒度的權限控制
訪問控制系統有一個比較困難的點，那就是細粒度的權限控制。這一點在訪問控制模型中你找不到答案，裏面只在比較宏觀的層面討論了人和權限的關系。但細粒度的權限控制需求在實際的業務場景中又切實存在著。比如一個企業有若幹臺虛擬機，有一些虛擬機用作 webserver，而有一些虛擬機用作數據庫，還有一些作為中間件服務器，比如 Zookeeper 等等，使用這些虛擬機的人各不相同，所以他們能看到並操作的虛擬機也應該得到嚴格的監管，否則可能會引起安全事故。
細粒度的權限控制關鍵點在於 “多細”，過於細致的控制會導致你的系統復雜度變高，不利於系統的可維護性。我的建議是只做到實例級別，而這其中也有一個例外，那就是對象存儲服務。
要做得有 “多細” 很大一部分取決於（第一點中）你資源標識的方式，如果你的資源描述方式合理，那麽更加細粒度地訪問控制並不會增加你系統的復雜度，這個我在下文中會提到。
3. 身份的多樣性
雲計算提供商要服務一個大客戶，滿足其業務架構只是其一，還有一個十分重要的條件就是滿足其組織架構的實際需要。大企業絕對有實力也有能力解決其本身的業務架構，其實上不上雲更多的是戰略性的考慮，他們會更看重雲服務的穩定性、安全性和可維護性。其本身的組織架構十分復雜，要想讓其沒有阻力地上雲，解決企業員工的身份問題首當其沖。所以現在主流的雲廠商都會提供多種身份的認定方式，例如：子賬號、組和角色。
4. 權限的描述方式
權限的描述方式也是十分重要的一點，可以說這個點設計的好壞決定了你後期是悠然地應對業務方的接入還是每天火急火燎地和各個業務方定協議定接口。
我們知道所有需要訪問控制的雲產品必然有其支持的動作（Action），每個產品資源 (Resource) 的描述方式也各不相同，同時，允許（Allow）還是禁止 (Deny) 針對某個資源的操作也是需要明確給出來的。這三個點構成了權限描述的三個要素。
如果在前期的設計中沒有充分思考這個問題，那麽恭喜你，你很有可能給自己埋了一個深坑。你很有可能設計幾張大表，來表示各個業務方支持的動作，資源以及用戶和他們的關系。出現這樣的設計是因為沒有真正理解訪問控制系統的業務領域。當你在設計這幾張表的時候其實意味著訪問控制系統在 “理解” 各個產品的功能，這對一個通用的訪問控制系統是致命的。
訪問控制系統作為一個底層/共享的通用系統，對外輸出的只能是能力，而不是去理解各個產品它們自己的業務領域。說到這裏，我還是推薦所有的技術人員有必要學習下 DDD 的理論，就算不用自己寫代碼，系統性地學習其戰略模式也會讓你收益很多。
5. 動態的授權體系
這一點相比於以上的 4 點來說要簡單，這是因為如果你的訪問控制系統已經很好地解決了上面的挑戰，那麽你也就自然而然地獲得了動態的授權體系。
之所以是動態的，是因為雲環境下用戶和權限的關系往往不是一成不變的。用戶在某個時刻希望獲得 A 授權，而在另外一個時刻又希望獲得 B 授權，而且有時授權還帶有時效性，當過了截至時間授權也就自動失效了。這種動態性的需求是真實存在的，但我認為滿足這個需求仰賴於對前 4 點挑戰的解決，如果把前面的設計做好了，那麽系統就自然滿足了動態性的需求，這是一個水到渠成的事情。
雲服務商如何設計訪問控制系統
AWS 做訪問控制（IAM） 的方法相對來說較為合理。IAM 將用戶身份劃歸為子用戶、組和角色，基本上這三種身份標識可以滿足身份多樣性的要求。IAM 關於權限描述的方式令人耳目一新，它使用領域專用（DSL）語言來描述權限，具體的形式如下：
{
“Version”: “2012-10-17”,
“Statement”: {
“Effect”: “Allow”,
“Action”: “s3:ListBucket”,
“Resource”: “arn:aws:s3:::example_bucket”
}
}
雲環境下的訪問控制系統最令人頭疼的問題就是資源和權限的描述方式，這種極致的靈活性很難通過設計表格來獲得。因為任何的以表為中心的設計方式都會映射到某個具體的領域模型上，又因為各個業務的權限控制各不相同，用 DSL 來將訪問控制和具體的權限理解分隔開是最為合適的方式。
通過一套特定的 DSL 語法來描述權限，訪問控制系統可以獲得極大的靈活性，同時也不需要理解具體的權限，對權限的理解還是由各個業務方自己控制，這樣系統就獲得了最大程度的解耦。訪問控制系統只用維護這套 DSL 語法就可以獲得無限的擴展性。
實際上，用 DSL 語法來描述權限也不是 IAM 首創，早在 2001 年就出現了響應的規範——XACML（可擴展的訪問控制高標識語言），該規範現在已經發展到 3.0 了。其大致的鑒權流程如下圖所示，如果對其原理感興趣的同學可以查看對應的資料。
總而言之，雲環境下的訪問控制系統面臨的挑戰很多，充分理解訪問控制的原理有助於理解代碼背後的意義，讓我們的系統設計不至於走偏。基於 DSL 的訪問控制模型已經成為業界的主流，但各個雲計算廠商自身的業務場景和面向的目標人群又各有不同，如何制定適應自身環境的 DSL 成為了一個關鍵。
網易雲基礎服務（蜂巢）今年 2 月14 日上線了訪問控制服務，目前已對六大業務支持訪問控制。同時，用戶可以授權給網易雲安全（易盾）和通信與視頻來訪問其在 NOS（對象存儲）的數據資源。
了解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/
對雲環境下訪問控制系統的思考