管理域 系統安全模型設計 1       修改歷史

版本	修改歷史	作者	描述	開發時間(h)
0.1	2007-9-5	LevinSoft	建立文件得基本結構、基本流程	5
0.2	2007-9-26	Levinsoft	優化了系統概念	0.1
0.3	2007-11-14	Levinsoft	豐富介紹內容 增加了安全框架的章節	1

2       介紹 安全永遠是Web應用程式必須要面對和解決的頭等大事。絕大多數的JavaEE企業級應用程式都有不同成程度的安全需求。通常來說，應用程式都需要保證幾個基本的安全需求。首先，應用程式必須能夠識別訪問者的身份；其次，應用程式必須對Web資源提供安全保證，拒絕未經授權的訪問；最後，在多層應用程式的模型中，應用程式還要有能力對業務邏輯元件提供保護，以防止非法使用者繞過Web層呼叫受保護的方法。 安全系統 包括兩個明顯的問題：認證和授權。認證就是識別使用者身份，一個使用者通過認證來告訴系統“我是誰”，從而確定使用者的身份。認證有多種方式，通常可以使用使用者名稱和口令實現認證，但是，還可以使用數字證書等形式實現更安全的認證。一旦確定了使用者的身份，下一步就是要確定使用者是否有權進行某種給定的操作，即授權。例如，是否能夠在網站首頁釋出一個文章。 由於使用者通常很多，對於每個使用者進行授權會非常麻煩。因此基於角色的許可權控制（Role Based Access Control, RBAC）就成為一種最流程的授權方式。 對於一箇中型或大型的軟體系統，安全管理是一個基礎模組，涉及到使用者、角色、操作許可權、選單、管理域等相關知識和模型，他們分別有自己的職責，同時相互關聯，共同構建起安全模型。 建立合理框架模型，能方便管理使用者、管理使用者許可權，保證功能可配置性和安全性， 有利於整個系統的演化。不合理安全模型影響整個軟體的使用，也不利於軟體的演化。 3       基本概念

3.1    系統 定義一：按一定的關係或功能組成的實體，能夠提供一項或一系列的功能。 定義二：滿足一系列目標的相互作用的各個部分的結構化的組合。 按照功能大小的來劃分：系統、模組、功能、操作。 對於一個大、中型軟體系統通常劃分為：系統、子系統、模組、功能、操作。根據功能的大小，可以把系統劃分為幾個子系統。可以把性質相同或類似的模型劃分到一個子系統中；功能通常和選單相對應；操作通常包括：增、刪、改、查、批量增加、批量刪除、批量修改、批量匯出等。 3.2    使用者 指在系統中能使用某些服務或功能的實體。 對於一個電信級別的支撐系統，通常使用者型別劃分：系統管理員、業務管理員、代理商、服務供應商、企業使用者、個人使用者等。當前業務平臺通常都是按使用者型別劃分的。 3.3    角色

3.3.1            角色概念 1.    角色是一種抽象的邏輯分組，代表具有同等許可權的使用者組。 2.    也稱“腳色”。戲劇、電影名詞。指劇中人物。 3.    “社會角色”的簡稱。指個人在社會關係位置上的行為模式。它規定一個人活動的特定範圍和與人的地位相適應的權利義務與行為規範，是社會對一個處於特定地位的人的行為期待。 故事影片中由演員扮演的人物。一般分為主要角色（簡稱主角）、次要角色（配角）和群眾角色等。 作品中的角色，是指漫畫、小說、戲劇或電影等著作中虛構的人物、動物或者其他生物，乃至於機器人。通常來講，這類角色的首要特徵是虛擬性和獨創性，其不同於現實生活中體現具體社會關係的真實人物。 4.    在軟體系統中，指登陸系統的使用者在系統位置上的行為模式。它規定登陸使用者的特定的範圍和與使用者的地位相適應的權利義務與行為規範，是軟體系統對一個特定地位的使用者的行為的期待。 5.    角色：角色是操作許可權的集合，通過將一個或多個角色分配給使用者，可以授予使用者對系統進行操作的許可權。角色有管理域屬性，這樣可以唯一的定位一個角色的範圍。 3.3.2            角色劃分

角色的劃分方式比較常見的是按使用者型別劃分和按功能劃分。 Ø        按使用者型別劃分：可以分為系統管理員、業務管理員、代理商、服務供應商、企業使用者等。 Ø        按功能劃分：可以分為系統管理員、業務管理員、計費管理員、帳務管理員、報表管理員等， 對於一個業務受理系統可以根據不同業務型別來定義不同的角色，例如：業務1角色、業務2角色等，這樣的好處就是直觀。當開展不同的業務時，就可以建立和分配不同的角色，同時給角色分配不同的許可權。 角色可以分級別，設計角色表時，可以採用子關聯的方式，增加一個父角色欄位。 一個系統，通常要設定超級管理(super system)角色，它是個特殊的角色，有系統最大的許可權，通常包括： 1．不需要進行資料許可權認證。檢視、操作大部分資料。但是出於安全考慮，例如：修改使用者賬戶、修改使用者訂購情況等，有些條件下，是需要限制的。 2．配置系統關鍵引數。 3．分配不同角色。 4．給角色分配許可權等等。 3.4    使用者與角色關係 由於角色一般不多，如一個部門種，角色可以分為管理員、經理、員工等幾類，資源和角色關聯，每個使用者根據自身的角色獲得相應的許可權，這樣可以大大簡化了授權的邏輯。比如：對於部門工資系統，每個員工都可以瀏覽自己的工資資訊，但是無權給自己加薪，而經理則可以調整員工工資的許可權，管理員具有為新員工建立工資記錄、定期備份資料等系統維護的許可權。若使用者A從員工被提升為經理，則該使用者的角色就從員工變成經理，從而獲得了經理級別的許可權。因此，在基於角色的許可權系統中，授權不和使用者直接掛鉤，而是和角色掛鉤，使用者再通過角色關聯，最終獲得相應的授權。

值得注意的是，使用者和角色通常不是簡單的多對一的關係，有一個使用者往往有多個角色，例如：一個操作員被任命為管理員，就具有了員工和管理員這兩個角色。3.4   

管理域：是一個虛擬的概念，是區分和過濾使用者和資料的關鍵引數。電信中，不同的區號代表不同的範圍，一個區號就可以代表一個域，一個域可以代表多個區號。

但是實際應用中，為了更好的擴充套件性，可以建立管理域模型，定義一定的標準，可以採用分級的管理模式，可以對物理存在的不同的區號資料進行管理。比如：0 代表省中心域，它可以管理全省的各個區號下的資料， 01 代表某某業務域，可以管理幾個區號下的資料。

通過管理域這個虛擬的概念，可以關聯幾個區號進行管理，在邏輯上，通過域可以把這些物理上不同的區號，進行管理起來。對計費來講，可以方便的區分訂購關係、話單等所屬的管理域。

對於一個區號，必須隸屬一個域。

域是可以分級別的。可以根據具體專案的大小，分成不同的域。對於一個省級別的專案，一般分成2級：省中心域級別和地市級。全國的可以分成3級，全國級別、省中心級別和地市級。

3.5    許可權

1.      操作許可權：操作許可權是對系統操作的約束，主要針對WEB頁面發起的請求，基於URL進行許可權過濾。

2.        資料許可權：資料許可權是指標對特定資料實體的資料行級的操作許可權，其中包括：增、刪、改、查等操作，每一個操作都對應一個細粒度的資料許可權，可以通過給角色分配相應的資料許可權，使角色具有該項功能。操作許可權一般對應於類中（對於struts，就是action中的方法）的方法。

3.        註冊許可權：把操作許可權插入到許可權表中。通常是建立兩個表：許可權目錄表、許可權表；之間採用1：0..*關係。一個許可權目錄，對應類，許可權對應類中的方法。

註冊許可權的方法： 一種是，開發專門的工具（錄入頁面），把相關的許可權（方法）輸入到資料表中。另外一種是，採用java 5 annotation新特性，開發專門的工具類，在執行函式之前，預先判斷是否要註冊許可權。

3.6    選單

當用戶使用功能或服務時，所操作連結。通常一個選單對應著一項功能。功能通常包括：增、刪、改、查等操作。

選單的設計為：一級、兩級、多級等。通常分成2級，父選單和子選單，父選單對應模組的命名，子選單對應功能。

選單庫表可以設計為子關聯的，方便支援多級選單模型擴充套件。也可建立選單目錄表，選單目錄和選單建立為：1:0..*的關係，一個選單通常只能隸屬於一個選單目錄。

可以設定選單是否顯示，控制使用者的功能（許可權）。通常的設計方式，使用者不能用的功能，把選單設計為不可見。

3.7    角色和域的關係

對於一個軟體系統，一個使用者可以擁有多個角色。正如：一個人在社會上擔任多個角色類似。

在設計中，角色和域是沒有直接關係的，角色決定使用者可以使用哪些功能，域決定使用者可以操作哪些資料，也就是說角色用來區分許可權，域用來區分資料。

3.8    使用者、角色、許可權和域的關係

系統中角色包含許可權，使用者對應多個角色，使用者只屬於一個域。如果一個許可權要在某個域上可用，必須指定許可權和域的關係。

關於角色和域的關係可以採用下面兩種實現方式：

Ø        給角色指定域，這樣在不同的域上配置不同的角色。實際上也相當於配置多個角色。

Ø        角色和許可權的對應關係加上域屬性，即一個角色在某個域上有哪些許可權。驗證許可權時需要加上域屬性，現在驗證許可權時只需要使用者和許可權標識，加上域屬性後驗證許可權時需要使用者＋許可權標識＋域。

3.8.1            兩種方式對比

對於第一種方式：         

Ø        優點：域、角色、許可權三者關係比較清晰，方便資料配置，許可權校驗時不需要域，實現相對簡單

Ø        缺點：按域定義角色會產生很多的角色定義，並且很有可能存在很多的冗餘角色。如，A域下的管理員許可權和B域下的管理員許可權相同，但卻需要定義兩個管理員角色，多個域的話就會有多個相同的角色。

對於第一種方式：

Ø        好處：避免了產生冗餘的角色資料，角色資料管理相對簡單；

Ø        缺點：許可權資料配置工作變的複雜；相對於第一點實現，許可權資料可能會有級數的增加，許可權驗證效能上可能會受影響；許可權驗證邏輯也相對複雜了。

3.9    實現方式舉例

    角色和域關聯，但是這個關聯，並不是每個域都要定義相同的角色，而是在給角色分配許可權的時候，把角色和許可權的對應關係加上域的屬性，即，角色-許可權-域；同時，在角色表中也增加域，即，角色表結構修改為 角色-域。

     舉例來說，全國01，四川省0101，成都市010101，（漢字後面的數字是每個域的編碼）。每個地方都有一個稱之為system專員，負責分配許可權的；全國的system定義了一個角色： “業務人員”，那麼在角色表中就產生一條資料： 業務人員-01；然後四川省和成都市的人，都可以看到父級別的角色，即，都可以看到“業務人員”這個角色。

    四川省的system，可以為“業務人員”這個角色分配許可權，然後產生的關聯資料是 ：業務人員-許可權-0101 ，只對四川省轄的使用者起作用，對別的省不起作用；向下慣行，成都市的業務人員預設的許可權也就是他的上級四川省剛剛配置的那個許可權。同樣，成都市的那個system也可以修改自己管轄的“業務人員”角色的許可權，產生的資料是：業務人員-許可權-010101。這樣成都市的角色就覆蓋了上級的角色許可權。

如果四川省建立了自己的角色，那麼別的省份是看不到的；成都市建立了新的角色，別的地市同樣是看不到的。

角色只有只有被分配了許可權和管理域後，才具有了行為模式。

    角色不是完全共享的，是可以分域的，而這裡並不需要每個域都建立相同的冗餘角色，根據管理域的分級概念，角色是可以繼承的。

    對角色的分配許可權，也是分域的，可以繼承上級的，也可以覆蓋上級。

3.10       生活中的例項

1． 政府的區域管理。中央、省、地市、縣、鎮、村等。

每一個省、地市等，都是區域的劃分。與系統中的管理域相對應。

2． 政府的權力管理。總書記、部長、省長、市長、縣長、鎮長、普通民眾等不同的角色。每一個人都需要和一個具體區域相關聯，一個區域省長不能管理同級別的其他省或上級區域，僅能管理本省內的事務。

總書記不能對省區域內的事務直接進行管理，他只能命令省長去管理。也就是說，採用系統分層模型。每一層，都有自己的職責。各層完成本層的職責。

4       參考設計模型

4.1    選單級別許可權模型

1． 每一個選單代表不同功能。

2． 不同的角色進行分配不同的選單。

3． 存放選單的表，可以設計為子關聯的。

4． 可以對選單歸類，引入選單目錄的概念。一個選單目錄和選單之間是：1：0..*的關係。

一箇中小軟體系統的使用者許可權模型參考例項：

4.2    資料操作級別許可權模型

1． 資料許可權可以精確到一個功能的增、刪、改、查、批量增加、批量刪除等操作。

2． 把細粒度的操作，專門的註冊到對應的資料庫表中。

3． 可以把這些操作級別的許可權資料分配給角色。這也是和選單級別許可權模型，最大的區別。該模型控制的粒度更細。

4． 驗證使用者許可權，可以通過專門的過濾器來實現。

一箇中小軟體系統的使用者許可權模型參考例項：

4.3    設計技巧

1． 在系統配置檔案中，增加是否註冊的標識，可以增加靈活性。

2． 在相關表中增加一個version欄位（Number），通過它的數字大小來決定程式是否去註冊新的許可權資料。例如：初時版本是0，隨後根據需要依次增加。這樣的好處：

a)      當類中（許可權元件）增加或修改新的方法（許可權），這時需要註冊，設定註冊許可權標識為開啟，同時，把這個許可權元件的版本進行調整為高數值。就可以方便的更新已有的許可權。

b)      不需要刪除資料庫中已有的許可權資料。不需要專門的sql去處理許可權資料，降低了工作量。

c)      由於版本的變化，可以方便的跟蹤某些許可權元件的變化情況。

5     安全框架的選擇 通常不建議自己開發安全邏輯，因為開發防攻擊的安全邏輯本身就不是一個簡單的任務。此外，自定義的安全邏輯可能會導致較低的可重用性。通常系統設計都是採用一些成熟的安全框架。下面是幾個例子: l         Java驗證與授權服務（Java Authentication and Authorization Service, JAAS） n         標準的認證和授權服務，他可以在可插入的身份驗證模組的基礎上，通過定義插入驗證模組的標準，系統管理員就能夠插入和配置適當的身份驗證服務，以滿足安全需求卻無需修改元件。不過，JAAS使用的是現有的Java 2安全模型，他根據認證和授權來限制資源和程式碼的訪問，不過，這些限制仍然侷限在較低層次的系統資源，例如,讀取檔案或使用網路介面等。通常情況下，伺服器環境下執行的程式碼都是可靠的且受信任的，因此，不太適合在伺服器端應用JAAS授權機制。 l         Acegi安全框架 n         是一個基於Spring開發的安全框架，為應用程式提供認證和授權功能。該框架採用“Spring方式”開發，包括依賴注入、AOP攔截、針對介面程式設計等最佳實踐。對於基於Spring的應用程式而言，Acegi提供了一個非常有用的外接式的安全架構，能夠非常容易的整合到實際的應用程式中。 n         基於角色的許可權管理許可權控制系統，它通過一系列可配置的元件構建了一個基於Spring IoC元件裝配模式的安全框架。

6       總結和展望

a)      簡單的總結前面知識