通用權限管理設計篇



通用權限管理設計篇（一）

一．引言

       因爲做過的一些系統的權限管理的功能雖然在逐步完善，但總有些不盡人意的地方，總想抽個時間來更好的思考一下權限系統的設計。

       權限系統一直以來是我們應用系統不可缺少的一個部分，若每個應用系統都重新對系統的權限進行設計，以滿足不同系統用戶的需求，將會浪費我們不少寶貴時間，所以花時間來設計一個相對通用的權限系統是很有意義的。

二．設計目標

       設計一個靈活、通用、方便的權限管理系統。

       在這個系統中，我們需要對系統的所有資源進行權限控制，那麼系統中的資源包括哪些呢？我們可以把這些資源簡單概括爲靜態資源（功能操作、數據列）和動態資源（數據），也分別稱爲對象資源和數據資源，後者是我們在系統設計與實現中的叫法。

系統的目標就是對應用系統的所有對象資源和數據資源進行權限控制，比如應用系統的功能菜單、各個界面的按鈕、數據顯示的列以及各種行級數據進行權限的操控。

三．相關對象及其關係

       大概理清了一下權限系統的相關概念，如下所示：

1.       權限

系統的所有權限信息。權限具有上下級關係，是一個樹狀的結構。下面來看一個例子

系統管理

        用戶管理

               查看用戶

                新增用戶

                     修改用戶

                     刪除用戶

       對於上面的每個權限，又存在兩種情況，一個是隻是可訪問，另一種是可授權，例如對於“查看用戶”這個權限，如果用戶只被授予“可訪問”，那麼他就不能將他所具有的這個權限分配給其他人。

2.       用戶

應用系統的具體操作者，用戶可以自己擁有權限信息，可以歸屬於0～n個角色，可屬於0～n個組。他的權限集是自身具有的權限、所屬的各角色具有的權限、所屬的各組具有的權限的合集。它與權限、角色、組之間的關係都是n對n的關係。

3.       角色

爲了對許多擁有相似權限的用戶進行分類管理，定義了角色的概念，例如系統管理員、管理員、用戶、訪客等角色。角色具有上下級關係，可以形成樹狀視圖，父級角色的權限是自身及它的所有子角色的權限的綜合。父級角色的用戶、父級角色的組同理可推。

4.       組

爲了更好地管理用戶，對用戶進行分組歸類，簡稱爲用戶分組。組也具有上下級關係，可以形成樹狀視圖。在實際情況中，我們知道，組也可以具有自己的角色信息、權限信息。這讓我想到我們的QQ用戶羣，一個羣可以有多個用戶，一個用戶也可以加入多個羣。每個羣具有自己的權限信息。例如查看羣共享。QQ羣也可以具有自己的角色信息，例如普通羣、高級羣等。

針對上面提出的四種類型的對象，讓我們通過圖來看看他們之間的關係。

 

    有上圖中可以看出，這四者的關係很複雜，而實際的情況比這個圖還要複雜，權限、角色、組都具有上下級關係，權限管理是應用系統中比較棘手的問題，要設計一個通用的權限管理系統，工作量也着實不小。

當然對於有些項目，權限問題並不是那麼複雜。有的只需要牽涉到權限和用戶兩種類型的對象，只需要給用戶分配權限即可。

在另一些情況中，引入了角色對象，例如基於角色的權限系統， 只需要給角色分配權限，用戶都隸屬於角色，不需要單獨爲用戶分配角色信息。

通用權限管理設計篇（二）——數據庫設計

   國慶前整的通用權限設計的數據庫初步設計部分，現在貼上來。

理清了對象關係之後，讓我們接着來進行數據庫的設計。在數據庫建模時，對於N對N的

關係，一般需要加入一個關聯表來表示關聯的兩者的關係。初步估計一下，本系統至少需要十張表，分別爲：權限表、用戶表、角色表、組表、用戶權限關聯表、用

戶角色關聯表、角色權限關聯表、組權限關聯表、組角色關聯表、用戶屬組關聯表。當然還可能引出一些相關的表。下面讓我們在PowerDesigner中畫出各表吧。

       各表及其關係如下：

      

1.       用戶表

用戶表（TUser）
字段名稱	字段	類型	備註
記錄標識	tu_id	bigint	pk, not null
所屬組織	to_id	bigint	fk, not null
登錄帳號	login_name	varchar(64)	not null
用戶密碼	password	varchar(64)	not null
用戶姓名	vsername	varchar(64)	not null
手機號	mobile	varchar(20)
電子郵箱	email	varchar(64)
創建時間	gen_time	datetime	not null
登錄時間	login_time	datetime
上次登錄時間	last_login_time	datetime
登錄次數	count	bigint	not null

2.       角色表

角色表（TRole）
字段名稱	字段	類型	備註
角色ID	tr_id	bigint	pk, not null
父級角色ID	parent_tr_id	bigint	not null
角色名稱	role_name	varchar(64)	not null
創建時間	gen_time	datetime	not null
角色描述	description	varchar(200)

3.       權限表

權限表（TRight）
字段名稱	字段	類型	備註
權限ID	tr_id	bigint	pk, not null
父權限	parent_tr_id	bigint	not null
權限名稱	right_name	varchar(64)	not null
權限描述	description	varchar(200)

4.       組表

組表（TGroup）
字段名稱	字段	類型	備註
組ID	tg_id	bigint	pk, not null
組名稱	group_name	varchar(64)	not null
父組	parent_tg_id	bigint	not null
創建時間	gen_time	datetime	not null
組描述	description	varchar(200)

5.       角色權限表

角色權限表（TRoleRightRelation）
字段名稱	字段	類型	備註
記錄標識	trr_id	bigint	pk, not null
角色	Role_id	bigint	fk, not null
權限	right_id	bigint	fk, not null
權限類型	right_type	int	not null（0:可訪問，1:可授權）

6.       組權限表

組權限表（TGroupRightRelation）
字段名稱	字段	類型	備註
記錄標識	tgr_id	bigint	pk, not null
組	tg_id	bigint	fk, not null
權限	tr_id	bigint	fk, not null
權限類型	right_type	int	not null（0:可訪問，1:可授權）

7.       組角色表

組角色表（TGroupRoleRelation）
字段名稱	字段	類型	備註
記錄標識	tgr_id	bigint	pk, not null
組	tg_id	bigint	fk, not null
角色	tr_id	bigint	pk, not null

8.       用戶權限表

用戶權限表（TUserRightRelation）
字段名稱	字段	類型	備註
記錄標識	tur_id	bigint	pk, not null
用戶	tu_id	bigint	fk, not null
權限	tr_id	bigint	fk, not null
權限類型	right_type	int	not null（0:可訪問，1:可授權）

9.       用戶角色表

用戶角色表（TUserRoleRelation）
字段名稱	字段	類型	備註
記錄標識	tur_id	bigint	pk, not null
用戶	tu_id	bigint	fk, not null
角色	tr_id	bigint	fk, not null

10.   用戶組表

用戶組表（TUserGroupRelation）
字段名稱	字段	類型	備註
記錄標識	tug_id	bigint	pk, not null
用戶	tu_id	bigint	fk, not null
組	tg_id	bigint	fk, not null

11.   組織表

組織表（TOrganization）
字段名稱	字段	類型	備註
組織id	to_id	bigint	pk, not null
父組	parent_to_id	bigint	not null
組織名稱	org_name	varchar(64)	not null
創建時間	gen_time	datetime	not null
組織描述	description	varchar(200)

12.   操作日誌表

操作日誌表（TLog）
字段名稱	字段	類型	備註
日誌ID	log_id	bigint	pk, not null
操作類型	op_type	int	not null
操作內容	content	varchar(200)	not null
操作人	tu_id	bigint	fk, not null
操作時間	gen_time	datetime	not null

通用權限管理系統設計篇（三）——概要設計說明書

 在前兩篇文章中，不少朋友對我的設計提出了異議，認爲過於複雜，當然在實際的各種系統的權限管理模塊中，並不像這裏設計得那麼複雜，我以前所做的系統中，

由只有用戶和權限的，有隻有用戶、權限和角色的，還有一個系統用到了用戶、權限、角色、組概念，這個系統是我在思考以前所做系統的權限管理部分中找到的一

些共性而想到的一個設計方案，當然還會有不少設計不到位的地方，在設計開發過程中會慢慢改進，這個系統權當學習只用，各位朋友的好的建議我都會考慮到設計

中，感謝各位朋友的支持。

    今天抽時間整了一份概念設計出來，還有一些地方尚未考慮清楚，貼出1.0版，希望各位朋友提出寶貴建議。

    大家也可以點擊此處《通用權限管理概要設計說明書》自行下載，這是1.0版本，有些地方可能還會進行部分修改，有興趣的朋友請關注我的blog。

     

1.      引言

1.1 編寫目的

本文檔對通用權限管理系統的總體設計、接口設計、界面總體設計、數據結構設計、系統出錯處理設計以及系統安全數據進行了說明。

1.2 背景

a、 軟件系統的名稱：通用權限管理系統；

b、 任務提出者、開發者：謝星星；

c、 在J2EE的web系統中需要使用權限管理的系統。

1.3 術語

本系統：通用權限管理系統；

SSH：英文全稱是Secure Shell。

1.4 預期讀者與閱讀建議

預期讀者	閱讀重點
開發人員	總體設計、接口設計、數據結構設計、界面總體設計、系統出錯處理設計
設計人員	總體設計、接口設計、數據結構設計、系統安全設計

1.5 參考資料

《通用權限管理系統需求規格說明書》

《通用權限管理系統數據庫設計說明書》

2.      總體設計

2.1 設計目標

權限系統一直以來是我們應用系統不可缺少的一個部分，若每個應用系統都重新對系統的權限進行設計，以滿足不同系統用戶的需求，將會浪費我們不少寶貴時間，所以花時間來設計一個相對通用的權限系統是很有意義的。

本系統的設計目標是對應用系統的所有資源進行權限控制，比如應用系統的功能菜單、各個界面的按鈕控件等進行權限的操控。

2.2 運行環境

操作系統：Windows系統操作系統和Linux系列操作系統。

2.3 網絡結構

 通用權限管理系統可採用Java Swing實現，可以在桌面應用和Web應用系統中進行調用。如果需要要適應所有開發語言，可以將其API發佈到WEB Service上。暫時用Java Swing實現。

2.4 總體設計思路和處理流程

在說明總體設計思路前，我們先說明本系統的相關概念：

1. 權限資源

系統的所有權限信息。權限具有上下級關係，是一個樹狀的結構。下面來看一個例子

系統管理

        用戶管理

               查看用戶

               新增用戶

               修改用戶

               刪除用戶

對於上面的每個權限，又存在兩種情況，一個是隻是可訪問，另一種是可授權，例如對於“查看用戶”這個權限，如果用戶只被授予“可訪問”，那麼他就不能將他所具有的這個權限分配給其他人。

2. 用戶

應用系統的具體操作者，用戶可以自己擁有權限信息，可以歸屬於0～n個角色，可屬於0～n個組。他的權限集是自身具有的權限、所屬的各角色具有的權限、所屬的各組具有的權限的合集。它與權限、角色、組之間的關係都是n對n的關係。

3. 角色

爲了對許多擁有相似權限的用戶進行分類管理，定義了角色的概念，例如系統管理員、管理員、用戶、訪客等角色。角色具有上下級關係，可以形成樹狀視圖，父級角色的權限是自身及它的所有子角色的權限的綜合。父級角色的用戶、父級角色的組同理可推。

4. 組

爲

了更好地管理用戶，對用戶進行分組歸類，簡稱爲用戶分組。組也具有上下級關係，可以形成樹狀視圖。在實際情況中，我們知道，組也可以具有自己的角色信息、

權限信息。這讓我想到我們的QQ用戶羣，一個羣可以有多個用戶，一個用戶也可以加入多個羣。每個羣具有自己的權限信息。例如查看羣共享。QQ羣也可以具有

自己的角色信息，例如普通羣、高級羣等。

針對如上提出的四種對象，我們可以整理得出它們之間的關係圖，如下所示：

總體設計思路是將系統分爲組權限管理、角色權限管理、用戶權限管理、組織管理和操作日誌管理五部分。

其中組權限管理包括包含用戶、所屬角色、組權限資源和組總權限資源四部分，某個組的權限信息可用公式表示：組權限 = 所屬角色的權限合集 + 組自身的權限。

角色權限管理包括包含用戶、包含組和角色權限三部分，某個角色的權限的計算公式爲：角色權限 = 角色自身權限。

用戶權限管理包括所屬角色、所屬組、用戶權限、用戶總權限資源和組織管理五部分。某個用戶總的權限信息存在如下計算公式：用戶權限 = 所屬角色權限合集 + 所屬組權限合集 + 用戶自身權限。

組織管理即對用戶所屬的組織進行管理，組織以樹形結構展示，組織管理具有組織的增、刪、改、查功能。

操作日誌管理用於管理本系統的操作日誌。

注意：因爲組和角色都具有上下級關係，所以下級的組或角色的權限只能在自己的直屬上級的權限中選擇，下級的組或者角色的總的權限都不能大於直屬上級的總權限。

2.5 模塊結構設計

本系統的具有的功能模塊結構如下圖所示：

2.6 尚未解決的問題

無。

3.      接口設計（暫略）

3.1 用戶接口（暫略）

3.2 外部接口（暫略）

3.3 內部接口（暫略）

4.      界面總體設計

本節將闡述用戶界面的實現，在此之前對頁面元素做如下約定：

序號	頁面元素	約定
1	按鈕	未選中時：[按鈕名稱] 選中時：[按鈕名稱]
2	單選框	○ 選項
3	複選框	□ 選項
4	下拉框	[選項,…,] ▽
5	文本框	|________|
6	TextArea	|…………|
7	頁籤	未選中時：選項名稱  選中時：選項名稱
8	未選中鏈接	鏈接文字
9	選中鏈接	鏈接文字
10	說明信息	說明信息

 

4.1 組權限管理

4.1.1包含用戶

組信息    組1        組11        組12        組…    組2        組21        組22        組…

所選擇組：組1 [包含用戶] [所屬角色] [組權限] [總權限] [修改] 用戶名   姓名     手機號   最近登錄時間 登錄次數 阿蜜果 謝星星 13666666666 2007-10-8    66 sterning xxx    13555555555 2007-10-8    10  ……

當用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該組所包含的用戶。

4.1.2所屬角色

組信息    組1        組11        組12        組…    組2        組21        組22        組…

所選擇組：組1 [包含用戶] [所屬角色] [組權限] [總權限] [修改] 角色ID   角色名稱   角色描述 1          訪客       --    2         初級用戶    --

當用戶選擇“修改”按鈕時，彈出角色樹形結構，操作人可以通過勾選或取消勾選來修改該組所屬的角色。

4.1.3組權限

組信息    組1        組11        組12        組…    組2        組21        組22        組…

所選擇組：組1 [包含用戶] [所屬角色] [組權限] [總權限]                 [保存] [取消]

4.1.4總權限

組信息    組1        組11        組12        組…    組2        組21        組22        組…

所選擇組：組1 [包含用戶] [所屬角色] [組權限] [總權限]                 [保存] [取消]

通過對已具有的權限取消勾選，或爲某權限添加勾選，來修改組的權限信息，點擊“保存”按鈕保存修改信息。

4.1.5組管理

       在下圖中，選中組1的時候，右鍵點擊可彈出組的操作列表，包括添加、刪除和修改按鈕，從而完成在該組下添加子組，刪除該組以及修改該組的功能。

組信息    組1        組11        組12        組…    組2        組21        組22        組…

所選擇組：組1 [包含用戶] [所屬角色] [組權限] [總權限] [修改] 用戶名   姓名     手機號   最近登錄時間 登錄次數 阿蜜果 謝星星 13666666666 2007-10-8    66 sterning xxx    13555555555 2007-10-8    10  ……

4.2 角色權限管理

4.2.1包含用戶

角色信息    角色1        角色11        角色12        角色…    角色2        角色21        角色22        角色…

所選擇角色：角色1 [包含用戶] [包含組] [角色權限] [修改] 用戶名   姓名     手機號   最近登錄時間 登錄次數 阿蜜果 謝星星 13666666666 2007-10-8    66 sterning xxx    13555555555 2007-10-8    10  ……

當用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該角色所包含的用戶。

4.2.2包含組

角色信息    角色1        角色11        角色12        角色…    角色2        角色21        角色22        角色…

所選擇角色：角色1 [包含用戶] [包含組] [角色權限] [修改] 組ID   組名稱     組描述 1      xxx1       -- 2       xxx2        --  ……

當用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該角色所包含的組。

4.2.3角色權限

角色信息    角色1        角色11        角色12        角色…    角色2        角色21        角色22        角色…

所選擇角色：角色1 [包含用戶] [包含組] [角色權限]                                  [保存] [取消]

通過對已具有的權限取消勾選，或爲某權限添加勾選，來修改角色的權限信息，點擊“保存”按鈕保存修改信息。

4.2.4管理角色

       在下圖中，選中組1的時候，右鍵點擊可彈出組的操作列表，包括添加、刪除和修改按鈕，從而完成在該組下添加子組，刪除該組以及修改該組的功能。

角色信息    角色1        角色11        角色12        角色…    角色2        角色21        角色22        角色…

所選擇角色：角色1 [包含用戶] [包含組] [角色權限] [修改] 用戶名   姓名     手機號   最近登錄時間 登錄次數 阿蜜果 謝星星 13666666666 2007-10-8    66 sterning xxx    13555555555 2007-10-8    10  ……

4.3 用戶權限管理

4.3.1所屬角色

用戶權限信息 xx公司    廣州分公司        阿蜜果        肖xx        yy…    北京分公司        zz1        zz2        zz3…

所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權限] [總權限] [修改] 角色ID   角色名稱   角色描述 1          訪客       --    2         初級用戶    -- …

當用戶選擇“修改”按鈕時，彈出角色樹形結構，操作人可以通過勾選或取消勾選來修改該用戶所屬的角色。

4.3.2所屬組

用戶信息 xx公司    廣州分公司        阿蜜果        肖xx        yy…    北京分公司        zz1        zz2        zz3…

所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權限] [總權限] [修改] 組ID   組名稱     組描述 1       組1         --    2       組2         -- …

當用戶選擇“修改”按鈕時，彈出組的樹形結構，操作人可以通過勾選或取消勾選來修改該用戶所屬的組。

4.3.3用戶權限

用戶信息 xx公司    廣州分公司        阿蜜果        肖xx        yy…    北京分公司        zz1        zz2        zz3…

所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權限] [總權限]                                   [保存] [取消]

通過對已具有的權限取消勾選，或爲某權限添加勾選，來修改用戶的權限信息，點擊“保存”按鈕保存修改信息。

4.3.4總權限

用戶信息 xx公司    廣州分公司        阿蜜果        肖xx        yy…    北京分公司        zz1        zz2        zz3…

所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權限] [總權限]                                   [保存] [取消]

通過對已具有的權限取消勾選，或爲某權限添加勾選，來修改用戶的權限信息，點擊“保存”按鈕保存修改信息。

4.3.5用戶管理

       當選擇了某用戶時，點擊右鍵，彈出菜單列表：修改、刪除、取消，點擊修改和刪除按鈕可以實現用戶的刪除和修改功能。

       選擇某個組織，例如下表中的“廣州分公司”，彈出菜單列表：添加子組織、刪除組織、修改組織、添加用戶、取消，點擊添加用戶按鈕可以實現用戶的添加功能。

用戶權限信息 xx公司    廣州分公司        阿蜜果        肖xx        yy…    北京分公司        zz1        zz2        zz3…

所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權限] [總權限] [修改] 角色ID   角色名稱   角色描述 1          訪客       --    2         初級用戶    -- …

4.3.6組織管理

       選擇某個組織，例如下表中的“廣州分公司”，彈出菜單列表：添加子組織、刪除組織、修改組織、添加用戶、取消，點擊添加子組織、刪除組織、修改組織按鈕可以實現組織的添加、刪除和修改功能。

用戶權限信息 xx公司    廣州分公司        阿蜜果        肖xx        yy…    北京分公司        zz1        zz2        zz3…

所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權限] [總權限] [修改] 角色ID   角色名稱   角色描述 1          訪客       --    2         初級用戶    -- …

4.4 操作日誌管理

4.4.1查詢操作日誌

操作名稱：|________|  操作人：|________|

操作時間從 |________| 到 |________| [查詢] [重置] [刪除]

編號    操作名稱    操作內容    操作人    操作時間

1        xx1         --        Amigo    2007-10-8

2        xx2         --        xxyy     2007-10-8

…

輸入上圖表單中的查詢信息後，點擊“查詢”按鈕，可查詢出符合條件的信息。

4.4.2刪除操作日誌

操作名稱：|________| 操作人：|________|

操作時間從 |________| 到 |________| [查詢] [重置] [刪除]

編號    操作名稱    操作內容    操作人    操作時間

1        xx1       --           Amigo      2007-10-8

2        xx2       --           xxyy       2007-10-8

…

輸入上圖表單中的查詢信息後，點擊“查詢”按鈕，可查詢出符合條件的信息。而後點擊“刪除”按鈕，可刪除符合查詢條件的操作日誌。

5.      數據結構設計

數據庫設計的模型請參見《通用權限管理系統_數據庫模型.pdm》。表的說明請參見《通用權限管理系統數據庫設計說明書》。

5.1 設計原則

5.1.1命名的規範

數據庫中表、主鍵、外鍵、索引的命名都以統一的規則，採用大小寫敏感的形式，各種對象命名長度不要超過30個字符，這樣便於應用系統適應不同的數據庫平臺。

5.1.2數據的一致性和完整性

爲了保證數據庫的一致性和完整性，往往通過表間關聯的方式來儘可能的降低數據的冗餘。表間關聯是一種強制性措施，建立後，對父表（Parent Table）和子表(Child Table)的插入、更新、刪除操作均要佔用系統的開銷。如果數據冗餘低，數據的完整性容易得到保證，但增加了表間連接查詢的操作，爲了提高系統的響應時間，合理的數據冗餘也是必要的。使用規則（Rule）和約束（Check）來防止系統操作人員誤輸入造成數據的錯誤是設計人員的另一種常用手段，但是，不必要的規則和約束也會佔用系統的不必要開銷，需要注意的是，約束對數據的有效性驗證要比規則快。所有這些，需要在設計階段應根據系統操作的類型、頻度加以均衡考慮。

5.2 數據庫環境說明

數據庫：MySql5.0

設計庫建模工具：PowerDesigner12.0

5.3 數據庫命名規則

表名以T開頭，外鍵以FK開頭，索引以INDEX開頭。

5.4 邏輯結構

pdm文件的名稱爲：《通用權限管理系統_數據庫模型》。

5.5 物理存儲

通過數據庫建模工具PowerDesigner12可以將pdm導出爲文本文件，將數據庫腳本放入文本文件中保存。

5.6 數據備份和恢復

數據庫需定期備份（每天備份一次），備份文件格式爲backup_yyyyMMdd，數據庫被破壞時，利用最新的備份文件進行恢復。

6.      系統出錯處理設計

6.1 出錯信息

錯誤分類	子項及其編碼	錯誤名稱	錯誤代碼	備註
數據庫錯誤	連接	連接超時	100001001
		連接斷開	100001002
	數據庫本身錯誤代碼	數據庫本身錯誤代碼	100002+數據庫錯誤代碼
TCP連接錯誤	連接	連接超時	101001001
		連接斷開	101001002
	其它TCP連接錯誤(socket自身錯誤代碼)		101002+ socket錯誤代碼
配置信息錯誤	未配置輸入參數		102001
	未配置輸出參數		102002
組管理部分自定義錯誤			103001——103999
角色管理部分自定義錯誤			104001——104999
用戶管理部分自定義錯誤			105001——105999
操作日誌管理			106001——106999

6.2 補救措施

爲了當某些故障發生時，對系統進行及時的補救，提供如下補救措施：

a．後備技術   定期對數據庫信息進行備份（每天一次），當數據庫因某種原因被破壞時，以最新的數據庫腳本進行恢復；。

7.      系統安全設計

7.1 數據傳輸安全性設計

SSH可以通過將聯機的封包加密的技術進行資料的傳遞; 使用SSH可以把傳輸的所有數據進行加密，即使有人截獲到數據也無法得到有用的信息。同時數據經過壓縮，大大地加快了傳輸的速度。通過SSH的使用，可以確保資料傳輸比較安全並且傳輸效率較高。

7.2 應用系統安全性設計

操作人的操作信息需要提供操作記錄。對系統的異常信息需進行記錄，已備以後查看。只有授權用戶才能登錄系統，對於某個操作，需要具有相應權限才能進行操作。

7.3 數據存儲安全性設計           

對於用戶的密碼等敏感信息採用MD5進行加密。