引言
企業云存儲，又稱企業網盤，是基于云計算理念推出的企業數據網絡存儲和管理解決方案，利用互聯網后臺數據中心的海量計算和存儲能力為企業提供數據匯總分發、存儲備份和管理等服務。企業云存儲必須保證企業數據的安全性，包括保密性、完整性和可用性。其中數據的保密性又包括兩個方面：ａ）對數據進行加密，確保非本企業的用戶（被授權的除外）以及云存儲運營商都無法獲得本企業數據的明文；ｂ）對數據進行訪問控制，確保只有被授權的本企業用戶才能訪問特定的數據，這也是本文研究的內容。
目前市場上比較流行的企業云存儲產品有聯想企業網盤、網易企業網盤和１１５企業網盤等。它們的訪問控制方案基本上都是采用自主訪問控制（ｄｉｓｃｒｅｔｉｏｎａｒｙａｃｃｅｓｓｃｏｎｔｒｏｌ，ＤＡＣ）和基于角色訪問控制（ｒｏｌｅｂａｓｅｄａｃｃｅｓｓｃｏｎｔｒｏｌ，ＲＢＡＣ）模型。但這兩種模型無法滿足企業云存儲的應用需求，主要表現為：ａ）隨著用戶和資源數量的增長，ＤＡＣ中訪問控制列表（ａｃｃｅｓｓｃｏｎｔｒｏｌｌｉｓｔ，ＡＣＬ）的規模急劇增加，難以管理和維護；ｂ）若要進行細粒度的訪問控制，必須對用戶進行精確區分，從而使ＲＢＡＣ需要定義大量的用戶角色，這給角色的分配和管理帶來困難；ｃ）它們都是靜態的授權機制，沒有考慮上下文環境對授權的影響。
基于屬性的訪問控制（ａｔｔｒｉｂｕｔｅｂａｓｅｄａｃｃｅｓｓｃｏｎｔｒｏｌ，ＡＢＡＣ）是將相關實體（如主體、資源和環境等）的屬性作為授權的基礎來進行訪問決策，它能解決復雜信息系統中的細粒度訪問控制和大規模用戶動態擴展的問題，為開放網絡環境提供了較理想的訪問控制方案。特別地，如果將身份、角色以及資源安全密級等信息也抽象化為實體屬性，ＡＢＡＣ則能實現傳統ＩＢＡＣ（ｉｄｅｎｔｉｔｙｂａｓｅｄａｃｃｅｓｓｃｏｎｔｒｏｌ，基于身份的訪問控制）、ＲＢＡＣ和ＭＡＣ（ｍａｎｄａｔｏｒｙａｃｃｅｓｓｃｏｎｔｒｏｌ，強制訪問控制）模型的功能。
ＡＢＡＣ基于主體、資源和環境等實體的屬性來制定訪問規則（或策略），并依照訪問規則來進行訪問決策，因而訪問規則的描述是ＡＢＡＣ研究的關鍵問題之一。ＸＡＣＭＬ（ｅｘｔｅｎｓｉｂｌｅａｃｃｅｓｓｃｏｎｔｒｏｌｍａｒｋｕｐｌａｎｇｕａｇｅ，可擴展的訪問控制標記語言）是一種基于ＸＭＬ的開放標準語言，它為ＡＢＡＣ提供了利用屬性進行訪問控制的策略描述語言，并給出了基本的ＡＢＡＣ授權框架，是ＡＢＡＣ策略描述語言的理想選擇。但在ＸＡＣＭＬ中，訪問請求和訪問規則都采用ＸＭＬ文件來描述，決策時由于需要解析這兩個ＸＭＬ文件，因而運行開銷較大。另外，訪問規則文件中的ＸＭＬ標簽很復雜，需要由專業人士編寫�；趯傩缘募用荏w制是ＡＢＡＣ的一種應用方式，它將數據加密和訪問控制融為一體，讓密文和密鑰分別對應一個訪問結構（規則）和一個屬性集合（或反過來），只有當屬性集合滿足訪問結構時才能解密數據。但該體制中的訪問規則的表達能力很弱，只能表達實體具有或不具有某種屬性，而無法將實體屬性與數值或字符串等進行比較。規則引擎也可以用來描述訪問規則，并且能表達較復雜的規則，但由于規則引擎并不是為訪問控制而建立的，故其實現較復雜，運行開銷較大。另外，由于規則是存儲在一定格式的文本文件中，其解析開銷也較大。還有一些文獻（如文獻［７，８］等）自己定義訪問規則的形式，并自己實現規則的解析和執行，這不但實現工作量巨大，而且在規則的表達能力以及規則的解析和執行效率上也很難具有優勢。對于企業云存儲的訪問控制方案來說：
ａ）用戶的每個操作都需要進行訪問決策，訪問規則的解析和運行開銷要小；
ｂ）訪問規則可能由普通用戶制定，規則的編寫要很容易；
ｃ）為了進行精細的訪問控制，規則的表達能力要很強。因此，現有的ＡＢＡＣ方案無法滿足企業云存儲的應用需求。為此，本文提出了一種滿足上述需求的適合企業云存儲應用的ＡＢＡＣ方案。此外，考慮到云存儲中資源數量巨大和層次結構的特點，該方案允許繼承訪問規則，以簡化訪問規則的制定和減小訪問規則的存儲空間。
1 企業云存儲系統的整體設計
1.1體系結構
企業云存儲系統的體系結構如圖１所示。
圖1企業云存儲系統的體系結構
用戶可以通過瀏覽器、PC客戶端、手彬平板客戶端或API來訪問云存儲服務器，并且用戶的訪問操作可分為兩類：
a)上／下載文件的操作；b)非上／下載文件的其他操作，如文件的刪除、目錄的創建等，本文將其稱為應用操作。用戶的任何訪問操作都需要事先詢問訪問控制器，訪問控制器則根據用戶屬性、被訪問資源的屬性、當前的環境、操作的類型以及訪問規則進行決策。只有當決策結果為true時該操作才被允許執行。其中用戶屬性和資源屬性存儲在屬性庫中，訪問規則存儲在規則庫中。為了保證服務性能，各種服務均采用集群服務器來提供可伸縮的服務。
1．2企業數據的存儲
系統采用HDFS(hadoop distributed file system)存儲企業的數據文件。HDFS是Google GFS的開源實現，是一個高度容錯的分布式文件系統，它能夠提供高吞吐量的數據訪問，并且可以部署在低廉的硬件上。系統采用單實例多租戶的方式為大量企業提供云存儲服務，每個企業對應一個英文縮寫，其數據存儲在“{HDFS數據目錄}／{企業英文縮寫}”目錄下，并采取一定的數據加密措施以保證其安全。
2 實體屬性及其存儲
2．1實體及實體屬性
訪問規則中允許使用主體(subject)、資源(resource)和環境(environment)三種實體。主體是指訪問者；資源是指被訪問的對象，包括文件和目錄，每個資源對應一個路徑；環境是指訪問過程的上下文，包括客戶端的類型和訪問時間等。
不同類型的企業之間存在差異，它們需要用到的主體(員工)屬性也有所不同，例如學校員工的屬性需要包括院、系、職稱等，而工廠員工的屬性需要包括部門、車間、工種等，并且有些企業可能需要用到一些特殊的員工屬性。因此，將主體屬性分為基本主體屬性和企業自定義主體屬性�；局黧w屬性由系統制定，包括用戶名、郵箱、姓名等一些通用且必需的員工屬性；而企業自定義主體屬性則是在企業注冊時設置的。企業在注冊時會連同注冊一個管理員用戶(admin)，其擁有管理該企業數據的最高權限。企業普通用戶的屬性由企業的admin在創建該用戶時填寫，且只能由admin修改，用戶自己無法修改。
資源屬性和環境屬性由系統制定。資源屬性包括路徑、類型(文件或目錄)、擴展名、大小、哈希值(以上三屬性僅針對文件)、修改日期、修改時間、擁有者和密級(普通、機密、絕密或繼承，繼承表示繼承其上級資源的值)；環境屬性包括客戶端類型、客戶端IP、(服務器)負載(0～1之間的數值)、(訪問)日期和時間。
2．2屬性的存儲
環境屬性無須存儲，由系統根據當時實際情況動態生成；資源屬性存儲在數據庫中。顯然，基本主體屬性和企業自定義主體屬性也需要存儲到數據庫中。但如果采用傳統的關系型數據庫來存儲企業自定義的主體屬性，無論存儲還是查詢時都需要對多個表進行操作，效率較低。另外，數據庫需要存儲海量的用戶屬性和資源屬性。因此，系統需要采用一個結構松散且擴展性好的數據庫。
MongoDB是一種開源的面向文檔的數據庫。一個MongoDB服務可以建立多個數據庫，每個數據庫可以有多個集合(相當于關系數據庫中的表)，每個集合可以存放多個文檔(相當于關系數據庫中的記錄)，文檔被存儲為鍵／值對的形式。MongoDB具有以下優點：
a)以文檔為單位存儲，易存儲對象類型的數據，很適合存儲實體的屬性；
b)模式自由，不需要提前設計結構，非常適合存儲企業自定義的主體屬性，且方便屬性的擴展；
e)支持的查詢語言非常強大，且支持建立索引以提高查詢效率；
d)自動分片功能支持水平的數據庫集群，支持云級別的伸縮性。
因此系統選用MongoDB作為數據庫。
假設某學校的英文縮寫為abc，那么注冊時需要用一個集合abc．attr來存儲其自定義的主體屬性，每個屬性用一個文檔表示。例如：
｛′ｎａｍｅ′：′學院′，′ｔｙｐｅ′：′枚舉′，′值′：′工學院，文學院，…′｝，
｛′ｎａｍｅ′：′職務′，′ｔｙｐｅ′：′枚舉′，′值′：′校長，院長，…，無′｝，
｛′ｎａｍｅ′：′入職日期′，′ｔｙｐｅ′：′日期′｝，
…
屬性的類型（ｔｙｐｅ）主要有兩個作用：ａ）區別該屬性的輸入方式，如枚舉類型的用選擇框輸入、日期類型的用日期控件輸入等；ｂ）提供檢查該屬性數據是否合法的依據。當增加普通用戶時，則在集合ａｂｃ．ｓｔａｆｆ中增加如下文檔：
｛
′用戶名′：′ｚｈａｎｇｓａｎ′，
′郵箱′：′ｚｈａｎｇｓａｎ＠ａｂｃ．ｅｄｕ．ｃｎ′，
′姓名′：′張三′，
…�。Ｆ渌局黧w屬性
′學院′：′工學院′，
′職務′：′系主任′，
′入職日期′：′２００６０７０１′，
…�。Ｆ渌髽I自定義主體屬性
｝
3 訪問規則的描述及存儲
3.1訪問權限
由于訪問規則的制定者是每個企業的管理員或普通用戶，如果權限的種類太多，會使得規則的制定過于復雜且容易出錯，因此系統目前只定義了三種權限，即讀、寫和管理，它們對應的具體操作如表1所示。
表1 權限對應的操作
3．2訪問規則的描述
每個資源的每種訪問權限都對應一條訪問規則。訪問規則為一邏輯表達式，由主體、資源和環境三者的屬性，算術、邏輯、關系等運算符，以及一些常用的函數構成。其執行結果為布爾值，當執行結果為ti'ue時表示允許訪問，為false時表示禁止訪問。本文采用Python邏輯表達式描述訪問規則，并采用eval函數執行規則。由于Python語言具有靈活且強大的表達能力，加上訪問規則表達式只要符合Python的語法，且執行結果為布爾值即可，因此訪問規則的表達能力很強，可以制定出非常復雜的控制規則，且書寫容易，只需掌握Python的基本語法即可。
在訪問規則中，實體用字典變量來表示，實體屬性用字典中的元素表示，元素的“鍵”對應屬性名，元素的“值”對應屬性值。由于字典變量無須(而對象類需要)事先定義結構，故當對實體屬性進行擴展時，無須修改程序代碼。本文還規定主體用變量Ｓ表示，資源用變量Ｒ表示，環境用變量Ｅ表示。以下是幾條合法的訪問規則實例：
規則１ （（Ｓ［′部門′］＝＝′財務部′）ａｎｄ（Ｓ［′職務′］ｉｎ｛′經理′，′副經理′｝））ｏｒ（Ｓ［′姓名′］＝＝′張三′），即允許財務部的經理和副經理，或者張三訪問；
規則２ （Ｓ［′用戶名′］＝＝Ｒ［′擁有者′］）ｏｒ（Ｓ［′用戶名′］＝＝′ａｄｍｉｎ′），即允許資源的擁有者或者管理員訪問；
規則３ （ＲＥＭａｔｃｈ（Ｅ［′客戶端ＩＰ′］，′＾２０２＼．１９２＼．１５９＼．′））ａｎｄ（ＹｅａｒＳｐａｎ（Ｅ［′日期′］，Ｓ［′入職日期′］）＞２），即允許ＩＰ地址為２０２．１９２．１５９．且入職超過２年的用戶訪問（ＲＥＭａｔｃｈ和ＹｅａｒＳｐａｎ是本文實現的正則表達式匹配函數與計算兩日期之間年份差的函數）；
規則４ （Ｒ［′類型′］＝＝′文件′）ａｎｄ（Ｒ［′大小′］＜２２０）ａｎｄ（Ｒ［′擴展名′］．ｌｏｗｅｒ（）ｎｏｔｉｎ［′．ｅｘｅ′，′．ｂａｔ′］），即允許訪問（如上傳）大小不超過１ＭＢ的非可執行文件。
3．3訪問規則的繼承與存儲
各企業的資源訪問規則連同資源屬性一起存儲在集合{企業英文縮寫}．res中。為了便于文件的歸檔和分類，以及便于用戶的檢索，各企業文件的組織通常都是成樹狀的層次結構。并且考慮到：a)資源(目錄或文件)的權限通常默認繼承上一級資源(目錄)的權限；b)擁有某個資源的讀權限通常必須擁有其上級資源的讀權限，而擁有某個資源的讀權限不一定擁有其下級資源的讀權限；c)擁有某個資源的寫權限通常也擁有其下級資源的寫權限，而擁有某個資源的寫權限不一定擁有其上級資源的寫權限；d)管理權限與寫權限類似。因此，系統為每種權限定義了兩個鍵：一個是inherit(繼承)，鍵值為布爾量；另一個是nile(規則)，鍵值為邏輯表達式字符串。各資源對應的文檔格式如下：
｛
′路徑′：′′，
′類型′：′文件′，
…�。Ｆ渌Y源屬性
′訪問規則′：｛
′ｒｅａｄ′：｛′ｉｎｈｅｒｉｔ′：，ｒｕｌｅ：′′｝，
′ｗｒｉｔｅ′：｛′ｉｎｈｅｒｉｔ′：，ｒｕｌｅ：′′｝，
′ｍａｎａｇｅ′：｛′ｉｎｈｅｒｉｔ′：，ｒｕｌｅ：′′｝
�。�
｝
資源各種權限的鍵值組合與該資源最終訪問規則的對應關系如表２所示。
表２ 資源的最終訪問規則
允許訪問規則的繼承，使得上一級資源的規則可被下一級資源重復利用，不僅大幅度減少了規則存儲的空間，而且大幅度減少了規則編寫的工作量。另外，本文將inherit為true、rule為空視為默認情況，此時無須存儲其鍵和鍵值。由于該情況通常會大量出現，從而可進一步節省大量的存儲空間。對于各企業的根目錄，本文將其密級設置為普通，將其訪問規則設置為
′ｒｅａｄ′：｛′ｉｎｈｅｒｉｔ′：ｆａｌｓｅ，′ｒｕｌｅ′：′ｔｒｕｅ′｝，
′ｗｒｉｔｅ′：｛′ｉｎｈｅｒｉｔ′：ｆａｌｓｅ，′ｒｕｌｅ′：
�。ⅲǎ樱�′用戶名′］＝＝Ｒ［′擁有者′］）ｏｒ
�。ǎ樱�′用戶名′］＝＝′ａｄｍｉｎ′）＂｝，
′ｍａｎａｇｅ′：｛′ｉｎｈｅｒｉｔ′：ｆａｌｓｅ，′ｒｕｌｅ′：
�。ⅲǎ樱�′用戶名′］＝＝Ｒ［′擁有者′］）ｏｒ
�。ǎ樱�′用戶名′］＝＝′ａｄｍｉｎ′）＂｝
4 訪問控制器
4．1開發框架
訪問控制器采用跨語言的服務開發框架Thrift進行實現。采用該框架，開發人員無須關注RPC(remote procedurecall，遠程過程調用)協議層和傳輸層的實現，而只需首先在Thirft文件中定義數據類型和服務接口；然后用Thrift編譯器編譯該文件產生相應語言(目前支持C++、Java、Python、PHP等10多種主流語言)的代碼文件；最后分別用相應的語言實現服務程序和客戶端調用程序。Thrift框架類似于Web Service，但其效率和開發的方便性是Web Service所不能比擬的。
4．2數據類型和服務接口的定義
訪問控制服務接口為每種訪問操作都定義了一個返回布爾值的訪問控制服務函數。Thrift文件的主要代碼如下：
ｓｔｒｕｃｔＲｅｑｕｅｓｔＰａｒａｍｅｔｅｒ｛
１：ｓｔｒｉｎｇｅｎｔERPｒｉｓｅ
�。玻海螅簦颍椋睿纾酰螅澹�
３：ＣｌｉｅｎｔＴｙｐｅｃｌｉｅｎｔｔｙｐｅ�。杜e類型，其定義省略
４：ｓｔｒｉｎｇｃｌｉｅｎｔｉｐ
｝
ｓｅｒｖｉｃｅＡｃｃｅｓｓＣｏｎｔｒｏｌ｛
… ／／省略其他讀寫操作的訪問控制服務函數
�。猓铮铮欤模椋颍停铮觯澹ǎ保海螅簦颍椋睿纾铮欤洌穑幔簦�，２：ｓｔｒｉｎｇｎｅｗｐａｔｈ，
�。常海遥澹瘢酰澹螅簦校幔颍幔恚澹�ERPａｒａｍｅｔｅｒ），
… ／／省略其他管理操作的訪問控制服務函數
�。猓铮铮欤樱澹簦遥酰欤澹ǎ保海螅簦颍椋睿纾穑幔簦瑁玻海遥澹瘢酰澹螅簦校幔颍幔恚澹�ERPａｒａｍｅｔｅｒ）
4.3訪問控制服務函數的實現
各服務函數在實現時，首先將訪問操作轉換為對某個（或某些）資源進行某種（或某些）權限的操作，然后調用決策函數Ｄｅｃｉｓｉｏｎ對操作進行決策并返回決策結果，Ｄｅｃｉｓｉｏｎ又是通過調用遞歸的決策函數ＲｅｃｕｒｓｉｖｅＤｅｃｉｓｉｏｎ進行決策。服務函數也采用Ｐｙｔｈｏｎ來實現。下面以ＤｉｒＭｏｖｅ為例說明服務函數的實現方法。
ｄｅｆＤｉｒＭｏｖｅ（ｓｅｌｆ，ｏｌｄｐａｔｈ，ｎｅｗｐａｔｈ，ｐａｒａｍｅｔｅｒ）：
�。颍澹簦酰颍睿ǎ模澹悖椋螅椋铮睿ǎ铮欤洌穑幔簦�，Ｒｉｇｈｔ．ＭＡＮＡＧＥ，ｐａｒａｍｅｔｅｒ）ａｎｄ
Ｄｅｃｉｓｉｏｎ（Ｆａｔｈｅｒ（ｎｅｗｐａｔｈ），Ｒｉｇｈｔ．ＷＲＩＴＥ，ｐａｒａｍｅｔｅｒ））
ｄｅｆＤｅｃｉｓｉｏｎ（ｒｅｓｏｕｒｃｅｐａｔｈ，ｒｉｇｈｔｔｙｐｅ，ｐａｒａｍｅｔｅｒ）：
4．4 Eval函數的安全性
由于訪問規則是由用戶編寫的，為了防止用戶在規則中執行惡意的代碼，如利用_import_(“OS”)．system(cmd)執行刪除系統文件和窺探系統信息的代碼，系統必須對規則中使用的變量和函數進行限制。這可以借助eval(expression[，globals[，locals]])函數的后兩個可選參數做到，其中globals用于指定expression中可用的全局變量和函數，locals則用于指定可用的局部變量和函數。本文在實現時允許規則中使用的局部變量為S、R和E，全局函數為REMatch和YearSpan等實現的函數。注意，Python內置的函數(如abs、len等)和內置對象的成員函數(如字符串的lower函數等)是不受這兩個可選參數限制的，因而訪問規則的表達能力能夠得到保證。
5 實例及優勢分析
下面將本文提出的ABAC方案與目前流行的三種ABAC方案，即基于XACML的方案、基于屬性的加密體制以及基于規則引擎的方案。結合實例進行對比分析，假設需要實現的規則為：僅當主體的用戶名等于資源的擁有者且客戶端類型為瀏覽器時才允許訪問。
5．1 訪問規則的編寫難度
基于屬性的加密體制無法實現該規則。在本文的方案中，該規則可簡單地描述為
（Ｓ［′用戶名′］＝＝Ｒ［′擁有者′］）ａｎｄ（Ｅ［′客戶端類型′］＝＝′瀏覽器′）
若采用基于ＸＡＣＭＬ的方案，規則文件的核心部分如下：
可見其規則編寫的難度很大，即使采用程序來生成該規則文件，代碼也很復雜。Drools是一個應用廣泛的開源規則引擎實現，若用其描述該規則，規則文件的核心部分如下：
若采用后者ｅｖａｌ的方式來表達規則，則規則的編寫與本文的方案類似，也很容易。
5.2訪問規則的執行效率
在一臺ＣＰＵ為Ｉｎｔｅｌ酷睿２雙核Ｅ８４００（主頻３ＧＨｚ）、內存為３ＧＢ的ＷｉｎｄｏｗｓＸＰ機器上，分別測試了該規則在三種方案（基于屬性的加密體制除外）下的（本地）執行時間，ＸＡＣＭＬ實現采用的是ＳＵＮ公司的ｓｕｎｘａｃｍｌ，測試結果如下：Ｄｒｏｏｌｓ約為１２００ｍｓ，ｓｕｎｘａｃｍｌ約為２００ｍｓ，本文方案約為０．０４ｍｓ。在前兩種方案中，由于分別需要解析文本文件和ＸＭＬ文件，故執行開銷較大，而本文方案無須解析文件，規則直接執行，故執行開銷很小。特別地，由于規則引擎并不是為訪問控制而建立的，Ｄｒｏｏｌｓ還實現了諸如對象修改、規則重復觸發等其他功能，故其實現復雜，運行開銷很大。此外，由于在基于屬性的加密體制中訪問控制和加密融為一體，故這里沒有測試其執行效率。
5.3訪問規則的表達能力
基于屬性的加密體制中訪問規則的表達能力很弱，只能表達實體具有或不具有某種屬性，而無法將實體屬性與數值或字符串等進行比較；其他三種方案的訪問規則中都能使用各種類型的變量，如算數運算符、關系運算符、邏輯運算符，集合操作，正則表達式等，并且可以自定義函數，從而表達能力都很強，但本文方案中規則的書寫更為簡潔明了。
6 結束語
目前市場上的企業云存儲產品采用的訪問控制模型無法滿足應用需求，雖然ＡＢＡＣ是非常理想的訪問控制模型，但目前已有的ＡＢＡＣ方案在訪問規則的描述方面存在著一些不足，仍然無法滿足應用需求，為此本文提出了一種新的ＡＢＡＣ方案，并給出了實現方法。該方案的設計與實現具有以下優點：
ａ）采用Ｐｙｔｈｏｎ邏輯表達式描述訪問規則，并采用ｅｖａｌ函數執行規則，從而使規則編寫容易，表達能力強，且執行效率高；
ｂ）規則中采用字典變量表示實體，從而當擴展實體屬性時無須修改程序代碼；
ｃ）考慮到云存儲中的資源具有層次結構的特點，并根據讀、寫和管理權限的特點，分別為不同的權限設計了相應的訪問規則繼承策略，不僅減少了規則存儲的空間，而且減少了規則編寫的工作量；
ｄ）采用模式自由的ＭｏｎｇｏＤＢ作為屬性存儲的數據庫，便于存儲企業自定義的主體屬性；
ｅ）采用Ｔｈｒｉｆｔ框架實現訪問控制器，從而能提供開放、跨語言、跨平臺，且高效的訪問控制服務。針對層次結構的資源設計通用的訪問控制模型和框架是筆者下一步的工作。
轉載請注明出處：拓步ERP資訊網http://m.nttd-wave.com.cn/
本文標題：一種基于屬性的企業云存儲訪問控制方案
相關文章
