任何一個(gè)開放系統(tǒng)(Open System), 只要它與外界有接口, 就存在安全問題, 越是商業(yè)級(jí)應(yīng)用越注重安全. 安全管理涉及很廣, 大到整個(gè)網(wǎng)絡(luò)安全的設(shè)定,小到具體按鈕的訪問, 如果你的系統(tǒng)哪天出現(xiàn)安全問題, 沒準(zhǔn)追根溯源能找到機(jī)房看門老頭, 呵呵, 玩笑話略過, 今天我們主要看看Drupal的用戶權(quán)限管理, 也就是訪問控制系統(tǒng).

權(quán)限管理的要素
我認(rèn)為, 一個(gè)權(quán)限管理系統(tǒng)主要由以下四要素組成: 訪問者, 管理對(duì)象, 操作和規(guī)則.

• 訪問者: 誰(shuí)干? who. 一般來(lái)說(shuō)是人, 嚴(yán)格來(lái)說(shuō)應(yīng)該叫主動(dòng)體, 這要看你的系統(tǒng)面向哪些用戶, 一般系統(tǒng)人機(jī)接口,機(jī)機(jī)接口都是存在的. 反正就是那些通過你系統(tǒng)開發(fā)的接口與你交互的東東.
• 管理對(duì)象: 干誰(shuí)? which. 就是被管理的東西, 比如倉(cāng)庫(kù)里的糧食, 博客系統(tǒng)的文章, 總之, 任何有管理要求的東西. 千萬(wàn)要記住的一點(diǎn)是: 就算垃圾也是有管理要求的.
• 操作: 干什么? what. 對(duì)應(yīng)具體操作, 比如寫文章, 運(yùn)糧食, 倒垃圾...
• 規(guī)則: 怎么干? how, when, where, 定義操作實(shí)施的附加條件, 比如登陸時(shí)間等.

權(quán)限管理的系統(tǒng)功能
可以說(shuō), 自從有了安全問題, 大家就在圍繞這幾個(gè)要素傷腦筋, 針對(duì)各種不同的管理需求, 也出現(xiàn)了各種不同的權(quán)限管理的方案, 如何在安全性, 操控性, 性能以及開發(fā)復(fù)雜性間取得平衡是恒古不變的主題. 為了聚焦今天的話題, 我們主要從系統(tǒng)功能角度來(lái)窺視一下, 看看一個(gè)權(quán)限系統(tǒng)到底是如何工作的.

1. 首先當(dāng)然權(quán)限的定義, 即識(shí)別出系統(tǒng)中需要進(jìn)行訪問控制的要素(管理對(duì)象, 操作, 規(guī)則), 并定義成相應(yīng)的權(quán)限, 這是整個(gè)權(quán)限系統(tǒng)的核心, 針對(duì)不同的管理粒度和管理要求, 會(huì)出現(xiàn)截然不同的實(shí)現(xiàn)方式.
2. 授權(quán), 即把權(quán)限與用戶關(guān)聯(lián), 最直接的方法是給用戶直接關(guān)聯(lián), 而最常見最有效的方式是使用角色(也有叫組的)
3. 鑒權(quán), 根據(jù)規(guī)則執(zhí)行權(quán)限的檢查, 以實(shí)施訪問控制, 看你的檢查點(diǎn)實(shí)現(xiàn)在哪呢, 同樣也是不同的要求有不同的實(shí)現(xiàn)
4. 最后, 應(yīng)該要能監(jiān)控, 一般記日志

是不是比較清楚, 把這幾個(gè)系統(tǒng)功能考慮完全, 并實(shí)現(xiàn)好, 你的系統(tǒng)就安全了一半; 另一半是什么, 是你的安全意識(shí), 天干物燥, 防火防盜, 只有真正樹立安全意識(shí), 才能有效地去應(yīng)用各種安全措施, 防范危險(xiǎn). 不幸的是, 我們大多數(shù)人都疏予管理, 閑置, 不管不顧.

Drupal的權(quán)限管理框架
首先我們來(lái)識(shí)別系統(tǒng)中具備哪些要素: Drupal是一個(gè)基于web的CMS系統(tǒng), 所以訪問者主要局限在管理員和普通web訪問用戶(User); 而管理對(duì)象則是CMS中的核心--內(nèi)容, 在drupal中它被抽象為節(jié)點(diǎn)(Node). (應(yīng)該還會(huì)有些其他的管理對(duì)象). 操作呢? 菜單, 按鈕, 在web系統(tǒng)里是不是都對(duì)應(yīng)到頁(yè)面, 也就是內(nèi)部路徑(例如: "node/1/view"), 規(guī)則沒什么特殊的: 操作時(shí)出現(xiàn)禁止頁(yè)面, 列表中不出現(xiàn)無(wú)權(quán)限內(nèi)容等.

Drupa采用角色來(lái)關(guān)聯(lián)用戶和操作, 每個(gè)角色是從方便系統(tǒng)管理角度出發(fā)來(lái)定義的一類具備相同操作界面或行為的訪問者, 但它不是簡(jiǎn)單的用戶或操作的分組, 而是他們的有機(jī)結(jié)合, 形象的說(shuō)就是一組權(quán)力的代名詞或者叫Permission Scheme. Drupall針對(duì)操作是否涉及到管理對(duì)象, 設(shè)計(jì)了兩個(gè)不同的鑒權(quán)流程, 以滿足不同的權(quán)限管理要求.

(1)與內(nèi)容無(wú)關(guān)的操作權(quán)限
權(quán)限定義
鉤子hook_perm, 定義了每個(gè)模塊的操作權(quán)限, 用操作名描述.

授權(quán)
按角色授權(quán), 權(quán)限被分配后, 存儲(chǔ)在數(shù)據(jù)庫(kù)表{permission}中.
鑒權(quán)
由函數(shù)user_access進(jìn)行實(shí)際的鑒權(quán)工作, 它的參數(shù)是賬號(hào)信息與操作權(quán)限名, 返回ture或false. 你可以在任何需要的地方調(diào)用該函數(shù)進(jìn)行鑒權(quán), 但系統(tǒng)提供了一套默認(rèn)的回調(diào)機(jī)制, 使得鑒權(quán)點(diǎn)實(shí)現(xiàn)簡(jiǎn)單一致. 這就是菜單路由注冊(cè)函數(shù)中的access_callback參數(shù), 該參數(shù)標(biāo)明了此菜單路由需要進(jìn)行訪問控制, 只有訪問回調(diào)函數(shù)驗(yàn)證通過, 才會(huì)被正確路由到對(duì)應(yīng)頁(yè)面.

鑒權(quán)鉤子, 模塊可以處理一些特殊的規(guī)則

(2)節(jié)點(diǎn)訪問機(jī)制(Node Access System)
drupal還提供對(duì)管理對(duì)象的訪問控制--節(jié)點(diǎn)訪問機(jī)制(Node Access System), 這是一套復(fù)雜的機(jī)制, 我還沒完全摸清. 它主要是在權(quán)限定義方面進(jìn)行了增強(qiáng), 它通過定義用戶, 操作與節(jié)點(diǎn)的綁定, 來(lái)建立一個(gè)節(jié)點(diǎn)訪問表, 這樣當(dāng)需要進(jìn)行管理對(duì)象關(guān)聯(lián)鑒權(quán)時(shí), 系統(tǒng)會(huì)執(zhí)行node_access函數(shù), 該函數(shù)會(huì)恰當(dāng)?shù)夭樵児?jié)點(diǎn)訪問表獲得用戶的權(quán)限, 以完成鑒權(quán).
我們?cè)賮?lái)看看這張節(jié)點(diǎn)訪問表, 用戶信息, 操作信息, 節(jié)點(diǎn)信息, OMG! m*n*P=? 如果還是按以前方式來(lái)定義, 那性能的低下可想而知, 所以綜合一般的權(quán)限控制需求, Drupal僅定義了三種的原始操作: view, update, delete, 而對(duì)于用戶則僅定義了一個(gè)抽象的二元組(realm, grant), 它與實(shí)際用戶間的映射由你自定義的節(jié)點(diǎn)訪問控制模塊行來(lái)決定, 這樣達(dá)到對(duì)用戶歸納的效果, 減小節(jié)點(diǎn)訪問表紀(jì)錄的數(shù)量級(jí).
這套機(jī)制主要通過節(jié)點(diǎn)模塊(Node Module)提供的一系列api和hook_node_grants鉤子和hook_node_access_records鉤子來(lái)實(shí)現(xiàn). 我們這次知道有這套東西即可, 不鋪開敘述.

Drupal的權(quán)限管理方法
1, 基本權(quán)限管理
盡管Drupal的權(quán)限管理機(jī)制是強(qiáng)大復(fù)雜的, 但其默認(rèn)的基本權(quán)限管理卻非常簡(jiǎn)單, 基于角色(role)和操作權(quán)限, 把操作賦予角色, 而把角色賦予用戶, 這樣用戶就能使用相應(yīng)的權(quán)限. 基本權(quán)限管理粒度較粗, 只能滿足一般的安全需求.

2, 按內(nèi)容類型鑒權(quán)
如果我們對(duì)管理對(duì)象有更精細(xì)的管理要求, 比如我想讓A角色能訪問page, B角色只能訪問story, 咋辦? 基本權(quán)限管理做不到了, 那我們就擴(kuò)展模塊. 內(nèi)容訪問模塊(Content Access )允許你對(duì)內(nèi)容類型按角色設(shè)置權(quán)限(查看, 編輯, 刪除). 其實(shí)Drupal6.2基本權(quán)限管理里也能設(shè)置按內(nèi)容類型進(jìn)行鑒權(quán), 因?yàn)閐rupal把所有節(jié)點(diǎn)類型的幾個(gè)基本操作都注冊(cè)了, 看下面這個(gè)丑陋的循環(huán), 呵呵, 這幾個(gè)也是漢化不到位的地方.

3, 按組鑒權(quán)
如果是個(gè)大公司, 有很多部門, 相互間都有安全需求, 比如:
1. 能按不同的部門創(chuàng)建不同的組, 它們都能管理其私有內(nèi)容
2. 組成員擁有組內(nèi)的權(quán)限
3. 跨組間允許指定某些特定的權(quán)限共享
4. 匿名用戶只能訪問標(biāo)識(shí)為"public"的內(nèi)容, 注冊(cè)用戶能訪問public和Restricted, 僅組成員能訪問private等
看到這么多需求, 則我們需要一個(gè)更復(fù)雜的權(quán)限管理, drupal目前有兩個(gè)擴(kuò)展模塊都能提供類似的功能:
(a) taxonomy_access modules
使用drupal的分類模塊的基本功能, 完成以上的權(quán)限控制, 這里有英文的教程, 步驟描述較清楚.
i, 定義一個(gè)詞匯表(Groups), 用來(lái)定義組(即公司部門); 把它應(yīng)用到所有內(nèi)容類型, 再添加2個(gè)條目(比如財(cái)務(wù), 研發(fā))
ii, 再定義一個(gè)詞匯表(Access), 用來(lái)定義訪問級(jí)別; 同樣應(yīng)用到所有內(nèi)容類型, 同時(shí)還要設(shè)置"必須"的選項(xiàng), 這樣保證創(chuàng)建內(nèi)容時(shí)必須選一個(gè)該
詞匯表中的條目. 加三個(gè)條目(public, Restricted, Private)
iii, 按基本權(quán)限管理的方法創(chuàng)建2個(gè)角色(財(cái)務(wù)人員, 開發(fā)人員), 再創(chuàng)建幾個(gè)用戶, 并分辨賦予對(duì)應(yīng)角色(張三->財(cái)務(wù), 李四->開發(fā))
iv, 前面都是基本管理,沒涉及到擴(kuò)展模塊, 現(xiàn)在打開"administer > user management > taxonomy access: permissions", 按照步驟開始設(shè)吧, 一個(gè)組鑒權(quán)系統(tǒng)完成, 祝你好運(yùn).

(b) 著名的OG
Organic Groups功能太強(qiáng)了, 上面的需求全部能滿足, 組或圈的概念是大型社區(qū)不可缺少的, 別猶豫了, 能用就用吧.

總之, drupal的權(quán)限管理機(jī)制非常靈活, 可簡(jiǎn)可繁, 每個(gè)系統(tǒng)都安全的需求都是不一樣的, 你們的權(quán)限管理有哪些特殊的好實(shí)現(xiàn), 拿出來(lái)show繡把.