基于BPM的航天設備信息管理系統及安全機制的設計與實現

發布時間：2023-07-25 10:07

第一章緒論 1

1.1研究背景及意義 1

1.2研究現狀 2

1.2.1設備信息管理系統研究現狀 2

1.2.2安全機制研究現狀 4

1.3研究內容 5

1.4論文結構 5

1.5本章小結 6

第二章航天設備信息管理系統及安全機制需求分析 7

2.1相關技術 7

2.1.1開發環境概述 7

2.1.2BPM 技術選型 7

2.1.3MVC開發模式 10

2.1.5通用訪問控制策略 11

2.1.6通用加密算法 12

2.2設備信息管理系統需求分析 13

2.2.1核心業務需求分析 13

2.2.2必要性分析 24

2.2.3可行性分析 24

2.3安全機制需求分析 24

2.3.1業務需求分析 24

2.2.2必要性分析 28

2.3.3可行性分析 28

2.4本章小結 28

第三章航天設備信息管理系統的設計與實現 29

3.1設備信息管理系統的設計 29

3.1.1系統設計原則 29

3.1.2系統概要設計 29

3.1.3核心模塊詳細設計 33

3.2系統數據庫設計 45

3.2.1系統數據表關系圖 45

3.2.2系統數據表詳細設計 46

3.3設備信息系統的實現 48

3.3.1開發環境介紹 48

3.3.2模型實現技術 49

3.3.3供應商管理 53

3.3.4設備采購申請流程 55

3.3.5設備驗收入賬流程 56

3.3.6其他資產入賬管理流程 58

3.3.7設備直接入賬流程 59

33.8設備領用管理流程 60

3.3.9特種設備、車輛管理 60

3.3.10預報管理 61

3.3.11基礎數據管理 62

3.4本章小節 62

第四章系統安全機制的設計與實現 63

4.1AES加密算法的優化 63

4.1.1AES加密過程的分析 63

4.1.2AES算法優化方案的設計與實現 68

4.2基于多粒度組合的訪問控制策略 76

4.2.1通用訪問控制策略的分析 76

4.2.2基于多粒度組合的訪問控制方案的設計與實現 80

4.3安全機制-密級標識 82

4.3.1密級標識機制設計 82

4.3.2密級標識機制實現 83

4.4安全機制-敏感數據加密 83

4.4.1數據加密方案設計 83

4.4.2數據加密方案實現 84

4.5安全機制-身份認證機制 86

4.5.1基于AD域的身份認證設計 86

4.5.2身份認證機制實現 89

4.6安全機制-訪問控制機制 89

4.6.1訪問控制設計 89

4.6.2訪問控制實現 90

4.7安全機制-安全審計及監控機制 91

4.7.1安全審計及監控機制設計 91

4.7.2安全審計及監控機制實現....... 93

4.8本章小結 94

第五章系統測試及結果分析 95

5.1系統運行環境 95

5.2系統功能測試 95

5.3系統安全機制測試 103

5.4系統性能測試 111

5.5本章小結 112

第六章總結與展望 113

6.1工作總結 113

6.2工作展望 113

參考文獻 115

致謝 119

第一章緒論

在互聯網信息技術迅猛發展的時代下，國有企業的信息化建設逐步展開，企業也在信息化的帶動下快速發展。不同領域的國有企業，信息化管理轉型的步調不一。航天單位的企業與我國航天事業的發展息息相關，其信息化程度也決定了企業的發展前景。本文以北京市某航天企業的設備管理信息化建設為研究背景, 論述了如何利用計算機技術實現航天設備信息管理系統的建設。本章節主要介紹課題研究背景、內容及現狀等。

1.1研究背景及意義

我國互聯網技術發展迅速，信息化水平處于穩步發展的階段，各個領域的企業跟隨信息化的步伐，逐漸完成企業信息化管理的轉型工作。航天領域的企業也在信息化建設的道路上不斷摸索，但航天企業的性質比較特殊，它直接為國家的航天事業效力，航天企業的發展也直接影響到了我國航天事業的發展，所以改善航天企業資源管理是非常重要的，每一個航天領域的企業都應該重視起來。如何利用信息化時代的產物提高航天企業管理效率也是我們必須研究的問題。

本課題是以某航天研究所的設備管理現狀為背景。該研究所采用傳統手段管理設備，這種管理方式具有管理效率低、設備資源無法達到最高使用價值、流程審批慢、信息易丟失泄露等缺點。具體管理方式及特點包括：人工采集數據，存在信息錄入錯誤、人力資源浪費、工作效率低等問題；采用紙質作為存儲信息的媒介，大數據量及復雜信息導致紙質文件較多、查找信息困難、紙質文件易丟失: 采用人工跑簽的流程驅動方式，存在流程審批較慢，節點審批越權等問題；流程審批跨部門，部門間協作不方便；設備種類及數量龐大；建賬和管理困難；人員角色及權限復雜，審批流程走向難梳理；高密文件易被泄露，給企業帶來損失等。以上是航天設備信息管理的現狀及弊端，在信息化技術發展迅速的今天，該航天企業與其他已完成信息化轉型的企業相比，存在很大的弱勢，也很難在激烈的競爭中取得優勢。現在各行各業都在享受著互聯網技術帶來的福利，如果不能趕上信息化的潮流，企業的發展將是被動的，所以為了促進航天企業的發展，提高信息化管理的力度，本課題將以該航天所作為研究實例，設計并實現航天研究所設備信息管理系統，系統雖然具有針對性，但是在技術上和設計理念上都可以為同行企業提供參考價值。

為了完成航天設備信息管理方式的轉型，需要詳細調查航天所的設備信息管

理現狀及信息化建設需求。設備管理信息化轉型目標包括：

1.實現管理流程、表單電子化。設備信息管理系統提供設備日常管理工作中需要的表單及流程，通過系統實現流程的自動流轉和表單信息的簽署；

2•特種設備特殊管理，實現設備定期檢驗及維修。

3•實現臺賬分級管理。通過身份鑒別、權限劃分、訪問控制、安全審計等手段實現設備臺賬的分級管理；

4.實現雙網運行。系統將同時部署到涉密網和民網上，流程和表單信息能夠通過擺渡進行交互；

5•固定資產編號的自動生成，設備主管根據設備類號，自動生成固定資產編號。

6•提供在線學習與考試，加強員工對設備的使用技能。

航天所的企業特性也是我們在信息化建設時需要注意的，航天所屬于軍民融合的軍工企業，具有涉密性，其涉密文件不能被泄露；員工日常工作環境均為內網環境，內外網文件需要靠數據擺渡并查殺病毒，確保內網系統及數據安全；航天所己經存在保證客戶端物理安全的設備監控平臺，員工登錄終端設備需要使用 USB Key進行身份認證。航天研究所的保密特性要求在進行日常業務時要保證敏感數據的安全。例如，數據和人員都要有密級，不同密級的數據允許被相應密級的人員訪問、某些資源指定由某些角色的人員訪問等。上述建設目標的實現，將會顯著提高航天研究所的業務管理效率，最終達到促進航天企業快速發展，為我國的航天事業做出貢獻的目的。

1-2研究現狀

無論企業的規模大小，企業發展均以設備資產作為物理基礎，因而設備管理的水平代表著企業發展的水平。為了深入了解設備管理的相關現狀，該小節將從企業設備管理現狀及信息系統安全機制現狀兩個方面展開論述。

1.2.1設備信息管理系統研究現狀

國外于上世紀70年代提岀了管理信息的定義，關于管理信息的概念定義為在合適的時間點向上級領導及其他人員提供從過去到未來的企業資源信息及管理方式，輔助信息獲取者做出合理的決策叫但此定義不是在計算機基礎上提出的。在上世紀八十年代中期，高登教授提出了被廣泛采納定義，他將管理信息系統定義為一個使用計算機技術來幫助人們對日常工作進行統計分析，計劃控制和決策的系統。該系統需要計算機硬件資源、軟件資源及數據庫的支持以完成建設。該系統的優勢就是通過給企業提供信息，幫助企業管理者正確地對企業業務管理和決策凹。國外的信息管理技術起步較早，隨著計算機技術的發展也經歷了幾個標志性階段。從上世紀五十年代至至今，經歷了事務、系統、決策支持及綜合服務階段。目前，信息系統的前景是在大數據、機器學習技術的推動下，讓系統具有智能性。設備信息管理系統是眾多管理系統中的一個實例，但信息化建設過程中也出現了不少問題，總結起來包括：設備業務繁瑣，業務邏輯混亂、沒有規范的系統建設機制、生產成本太高，不利于企業發展、沒有高新專業技術支撐，系統穩健性不高、系統開發周期太長等。

設備信息管理系統不同于ERP (Enterprise Resource Planning)系統。ERP 系統著重優化管理企業的整體資源，而設備信息管理著重于設備整個生命周期內的人、物、事務的細致化管理；ERP系統涉及的應用領域較為復雜，圍繞市場導向開展業務活動，提高企業綜合競爭力，而設備信息管理系統專門面向企業設備，提高企業在設備管理的能力。從理論上，可以將設備信息管理系統作為ERP系統的一個子集。目前有很多優秀的ERP系統廠商，包括智邦國際ERP系列、用友ERP、金蝶K/3、東軟ERP、Aisino ERP A6等⑶。通過調研這些ERP系統，發現沒有專門提供基于工作流的設備信息管理服務，大多數系統是專注于企業綜合管理，結合上述ERP系統與設備系統的差異分析，得出ERP系統不適合專門管理企業設備資產，特別是航天領域的企業。

我國已經有很多提供設備管理的廠商，包括北京乾元坤和、晨科、大唐思拓等。以上廠商提供的都是商業化產品，在功能服務上以滿足大眾化需求為重點。乾元坤和提供的設備管理系統表現出了強大的全程動態管理性能，融入了設備使用及管理者的日常工作需求，但該系統將設備管理子系統、采購管理子系統及庫存管理軟件分開管理，且無法提供強工作流驅動的設備生命周期內的業務活動，固定的軟件框架業限制了軟件開發的擴展性和系統的維護性；晨科設備信息管理系統是一款通用性極強的管理軟件，無法滿足航天企業因設備種類不同而管理不同的需求，其提供的服務類似于乾元坤和設備管理系統；大唐思拓設備管理系統貫徹人體健康學預防為主，以設備臺賬健康檔案管理為基礎，建立預防、診斷、整治三個層次的設備管控體系，而航天企業的設備管理是以實現流程化管理設備生命周期的業務為目的，并支持在線學習各類設備使用管理服務，所以大唐思拓設備管理系統也不適合航天研究所的設備管理需求。通過以上設備信息管理系統的現狀分析，發現大部分設備管理系統廠商均是提供通用性的大眾化產品，無法滿足航天研究所的特殊需求，設計適合航天研究所設備管理的系統是非常有必要的。

另外，大多數企業的設備管理模式大多是基于流程驅動的，根據流程引擎的不同，國內外的工作流程引擎產品也層出不窮，為了解決流程的跨流程引擎使用的問題，BPMN2.0標準將業務流程的可視化和底層的XML表現進行了標準化, 這極大地改進了建模工具之間的交互性。在建設基于工作流的系統時，為開發者提供了較多的選擇。

1.2.2安全機制研究現狀

在系統安全建設上歐美等發達國家起步較早，在上世紀已在國內或地區內建設了涉密網絡，涉密網絡在適用對象和安全機制上有所不同，但涉密網的建設實現了在網絡上安全傳輸信息的目的⑷。后來美國又利用量子態不可復制的原理研發出一種量子密鑰分發技術，由于該技術在理論上不可被竊聽的特性使得其安全性非常高。發展中國家在發達國家的影響下，也在不斷研發適合本國的涉密信息安全保護基礎措施。以印度的安全基礎設施建設為例，其在本世紀初結合數字簽名、加密算法等技術提出了基于數字證書的安全信息交換技術，隨著密碼學技術的發展，該技術也在不斷成熟，能夠很好地提高域間信息交換的安全性⑷，我國在信息交換安全機制上也借鑒了這種技術，但考慮到涉密信息系統的特殊性及信息敏感性，我們能夠借鑒的資源和公開的公共資源并不多。在建設我國企業的涉密信息管理系統時，還需要根據我國國情和企業實際需求來完成。

在計算機技術發展的過程中，我國國有企業發生過很嚴重的涉密信息泄漏事件，每次信息泄露事件的發生都給企業造成不同程度的損失。信息泄露主要是由于信息管理和技術上不完善，為了提高涉及秘密信息的系統安全性，國家保密局提出了相關管理規定和技術標準，在國家規定的約束和監督下，我國對系統安全的建設逐漸形成了完善的管理機制。我國保密局于2005年發布了涉密信息管理辦法及技術要求，提出了分級保護⑸。涉密系統的分級保護主要是對物理、運行、信息及安全保密管理提出了技術規范要求［嘰以上四個方面對涉密系統的資源訪問控制、訪問系統時的身份鑒別及數據完整性提出了要求。首先，訪問控制方面, 需要對人員和權限嚴格把控。目前有多種訪問控制技術，每種訪問方式的粒度與對象都不同，可按需選擇；其次，身份鑒別方面，可以采用成熟的身份鑒別技術，例如復雜口令、域認證、USB登錄等方式，但在技術選型時需要根據系統實際運行環境來選擇，比如在具備天然安全屏障的前提下，推薦選擇較為方便的身份認證方式；最后，數據完整性包括存儲和傳輸完整性，可使用密碼學技術保證數據完整性。系統建設使用到的各項技術將在第二章節中介紹。在安全機制建設時需要根據企業信息化管理系統的實際需求，設計一套適合企業安全要求的機制。根據企業實情建設安全機制是為了減少成本投入，達到有效控制信息安全的目的。

1.3研究內容

在研究背景和研究現狀的論述下，課題研究內容從宏觀角度來看可以分為兩個內容，即如何建設設備信息管理系統、如何建設系統安全機制。在對兩個研究內容深入調研之后發現，每個研究內容又包含多個研究點。

1.BPM 框架的研究。BPM 解釋為業務流程管理(Business Process Management)o航天設備管理是基于業務流程的管理方式，系統核心功能是通過工作流驅動實現的。在2.1.2小節中，將詳細介紹目前專門提供業務流程開發服務的BPM框架，通過對比各個廠商提供的BPM服務及調研系統建設需求及建設目標，完成業務流程開發技術選型工作。最后介紹當選的BPM框架核心組件, 以及各個組件在業務流程構建過程中的作用。

2.基于BPM建設符合航天業特色的設備信息管理系統。該部分內容是課題工作量的體現。首先，通過調研航天研究所設備管理現狀，確定所內對于設備管理信息化建設的業務需求和非業務需求；其次，根據建設目標和需求分析設計系統功能模塊；然后，設計并實現設備信息管理系統。在系統設計時會考慮到功能模塊及數據等的安全性需求，但為了使論文結構更加清晰，作者把系統和安全機制分開論述。

3.航天設備信息管理系統安全機制的研究、設計與實現。首先，通過調研涉密信息系統的安全技術體系、航天設備信息管理系統實際運行環境以及研究所對信息系統安全性的要求，確定針對航天設備信息管理系統的安全機制，即密級標識、身份鑒別、數據加密、訪問控制、安全審計等；其次，根據安全機制重要性占比及系統實際需求，對數據加密和訪問控制機制進行了深入研究。對于數據加密，提出了 AES加密優化算法；訪問控制方面，提出了多粒度訪問方式組合的訪問控制方案。最后，在確定了安全機制的設計方案后，根據業務需求，在相應的功能模塊和數據主體上實現安全機制。該部分內容將在第三章詳細論述。

1.4論文結構

本課題的軟件開發模式選擇經典的瀑布模式，論文的結構也是依據軟件開發的主要階段分為如下幾個章節：

第一章緒論。該章節的核心內容主要是論述課題背景、研究內容和意義，分析航天研究所設備管理實際現狀，強調研究的必要性，并介紹論文結構安排。

第二章航天設備信息管理系統及安全機制的需求分析。該章節主要介紹通用技術、系統及安全機制需求分析。相關技術小節不僅介紹了通用技術，還確定了系統建設技術選型。通過對系統及安全機制的需求分析，為功能設計做了充分

的鋪墊工作。

第三章航天設備信息管理系統的設計與實現。首先確定系統功能模塊，分模塊詳細介紹業務功能的設計。其次介紹了系統功能模塊實現過程，包括流程模型、表單模型、事件觸發、適配器等的實現過程。

第四章安全機制的設計與實現。該章節首先介紹了安全機制中的數據機密和訪問控制優化創新的研究過程，其次介紹了系統整個安全機制的設計，并論述了安全機制在系統中是如何實現的。

第五章實驗結果及結果分析。測試系統功能是否實現，確保系統正常運行。由于該課題研究并實現的系統內容較多，在測試章節只是抽取了一部分核心功能作為代表完成測試內容。

第六章工作總結與展望。雖然課題研究范圍內的工作己經完成，但是隨著互聯網技術的發展，在系統可靠性及安全性方面還需要技術的更新，從而不斷地優化系統。

1.5本章小結

本章為論文緒論部分，主要論述了課題的研究背景及研究意義，以研究所設備管理信息化建設的實際需求作為切入點，強調課題研究意義。通過論述設備信息管理系統的研究現狀及航天研究所設備信息管理的特殊背景，引出建設一套適合航天研究所特性的設備信息管理系統的必要性，然后根據研究背景及研究現狀確定研究內容。最后，闡述論文的整體結構，課題所有內容將通過六章內容進行論述。

第二章航天設備信息管理系統及安全機制需求分析

本章節主要介紹設備管理信息化建設涉及到的通用技術、系統及安全機制的需求分析。通用技術小節中主要介紹開發環境、業務流程管理技術平臺選型及系統安全方面的通用性技術；系統需求內容主要包括航天研究所業務型和非業務型需求，業務型需求是確定系統需要提供哪些日常辦公服務，非業務型需求包括系統可行性、必要性及安全方面的需求。

2.1相關技術

本節主要介紹建設設備信息管理系統用到的核心技術，在技術選型時，需要基于航天設備信息管理系統的應用場景及部署方式；其次，還需要調研目前實現基于工作流模式的功能模塊的開發技術；最后，確定建設航天設備信息管理系統需要選擇什么樣的技術來實現。

2.1.1開發環境概述

航天設備信息管理系統采用瀏覽器、服務器訪問方式。目前有很多可以提供應用系統開發服務的框架，以java語言為例，包括Struts、Spring、Hibernate、 SpringMVCs SpringBoot等框架；提供應用服務的服務器包括Apache、Tomcat、 JBoss> Nginx、Jetty等；提供數據存儲服務的數據庫包括SQL Server、Mysqk Oracle等。在技術選型時，需要把航天設備信息管理的特殊性放在第一位考慮。為了提高系統健壯性及系統擴展性，也為了促進信息化建設過程，開發設備信息管理系統采用MVC系統開發模式、BPM平臺、Eclipse集成開發環境、Tomcat 服務、SQL Server 2008數據庫、安全技術體系內的核心機制等技術。另外前端頁面主要由HTML、CSS、JS、EXTJS、AJAX等技術實現。

2.1.2 BPM技術選型

BPM (Business Process Management),解釋為業務流程管理。業務流程管理能夠為企業實現眾多業務環節的整合和全面管理，BPM使用各種方法來發現、建模、分析、測量、改進和優化自動化業務流程，完成對企業管理環節的整體把控。BPM側重于通過管理業務流程來提高業績，用于管理企業流程的任何方法的組合都是BPM范疇的，流程可以是結構性且可重復性、非結構性且可變性。 BPM管理包括的主要內容參見圖2-1 o業務流程管理的概念不同于工作流

(Workflow)的概念，Workflow是指在計算機環境下實現業務管理過程自動化執行。工作流實例需要按照一定的規則傳遞文檔、數據信息及審核任務等，其目的是完成業務管理的自動化，工作流是BPM的一個子集。工作流系統地組織資源到轉換資料、提供服務或處理信息的流程中，并由有條理且可重復的業務活動模式組成⑺。

圖2-1 BPM生命周期活動內容

傳統的信息系統開發方法具有效率低的弱勢，這種方法沒有把基于流程的業務辦理放在系統建設的核心位置，也無法強調流程管理的重要性。業務流程管理模式的出現提出了一種新的系統建設方法。BPM更加看重信息系統開發中的商業需求，較為清晰地定義業務流程管理的概念，并在系統建設中落實固。目前 BPM方面的研究主要包括理論基礎、實現技術與應用。理論基礎介紹BPM的模型和體系的研究；實現技術包括流程建模、事務及驅動等；應用方面主要研究 BPM的應用方法和更新換代。

課題研究的設備信息管理系統主要業務是由業務流程驅動完成的，原生的 BPM流程引擎能夠實現基于流程引擎的功能模塊的開發，但其穩定性和可靠性不如市面上BPM廠商提供的平臺，也考慮到航天所信息化建設的急切性，所以選擇綜合實力較強的BPM平臺來完成系統開發。截止到2016年，市面上綜合實力較強的BPM廠商主要包括AWS BPM (炎黃盈動)、FlowPortah H3、K2 等。各BPM平臺比較分析的結果如表2-1所示。

表2T BPM平臺綜合實力對比

BPM

指標 AWS

BPM FLOW

PORTAL H3

BPM K2

BPM

平臺 Java .net .net .net

開發效率較高高高高

開發平臺有有有無

(續上表)

!^\bpm AWS FLOW H3 K2

i指標 BPM PORTAL BPM BPM

1綜合實力 I第一第二第三 |第四

根據以上BPM平臺能力對比結果，綜合考慮航天設備信息管理系統的建設目標，選擇了 AWS BPM平臺作為系統開發的業務流程驅動平臺。AWS BPM中包含多個核心組件，下面將詳細論述。

一、業務流程的構建

業務流程構建的核心是建模。流程實例包含開始和結束節點，中間由若干人工或系統審核節點、子流程組成a〕。節點之間通過路由規則連接，實例具有初始順序流。網關是指人工審核規則和系統規則。流程模型中包含畫布、泳池、泳道等必須元素。另外，還包括系統規則、人工審核規則、節點事件和流程事件等非必須組件。業務流程的構建需要基于數據模型和表單模型，數據模型采用對象關系映射的設計思想；表單模型將數據庫表中的字段展現給用戶，其綁定在流程模型上并由流程實例激活。

二、事件編程

事件是一種軟件架構的設計模式，事件容器捕捉到事件到達并回調相應的代碼邏輯。事件編程中用到的核心技術包括標準的Java編程、SDK包提供的Local API、JDBC編程以及CC (Connection Center) API和SOA技術相關的集成開發。事件編程主要包括流程事件編程、節點事件編程、子流程事件編程、擴展按鈕事件、身份驗證事件等。

流程事件是以流程為粒度的全局觸發事件，即允許在流程模型被工作流引擎實例化執行過程中觸發，流程間的流程事件相互獨立。系統開發中主要用到的流程事件包括流程啟動前事件(WMBeforeCreatedProcessInstance)、流程啟動后事件(WMAfterCreatedProcessInstance )、流程干擾結束事件 (WMAbortProcessInstance) > 流程自然結束事件(WMCompletedProcessInstance) 等。

節點事件與流程事件相似,是由工作流引擎在執行任務過程中觸發一系列的事件，能夠將當前節點的工作流上下文信息傳遞給事件處理程序，節點事件觸發采用IOC思想，將擴展代碼織入到業務邏輯中。節點事件模型如圖2-2所示。

圖2-2節點事件關系圖

適配器(Adapter)是一種插拔接口，用于改變原始類的行為，在系統中提供了登錄和消息提醒的服務。登錄適配器用于增強用戶身份認證的功能，除了復雜口令機制，還可以使用AD域認證、CA認證、指紋識別等機制加強身份認證。消息適配器用于給系統用戶發送待辦消息，消息的發送可以通過郵件或待辦任務這兩種方式來實現。適配器采用了設計模式中的裝飾者模式的理念，在原有功能上進行加強和擴展，在兼容原有功能的前提下，向前擴展新功能。裝飾者設計模式增強了原有代碼的功能，也方便開發者擴展業務代碼。在適配器核心實現代碼中，可以按照實際需求自定義身份證方式。

四、后端集成開發

后端任務集成模塊的開發主要包括定時器模塊及數據格式處理模塊。定時器模塊是用于控制任務開啟時間，例如在某一模塊中需要設置定時任務，通過使用定時器設置目標時間，在到達目標時間時通過消息適配器給用戶發送待辦通知。定時器模塊主要包括兩個接口，分別是定時任務接口和任務觸發器接口。定時任務接口是實現定時觸發的業務邏輯類，任務觸發器接口是根據業務需求制定的觸發條件=數據格式處理模塊是對各類文件解析過程進行封裝,實現代碼高重用性o 系統建設中使用了 XML和JSON數據格式。

2.1.3 MVC開發模式

傳統的系統開發模式是前后端程序都糅合在一起，各功能層代碼不純粹，系統在進行維護和功能擴展時工作量會很大。MVC模式將用戶界面、業務邏輯和數據庫交互層相互獨立起來，即MVC模式中的視圖層(VIEW)、模型層

(MODEL)和控制層(CONTROLLER)-三層分離的好處是各層各司其職，優化系統開發過程。三層的關系如圖2-3所示，控制層是視圖層和模型層的中間層, 視圖層負責展現數據信息給用戶；控制層主要實現在前端頁面發送請求時，查找處理該請求的業務代碼，并由之處理請求；模型層負責將處理后的數據保存到數據庫,或者從數據庫中取出數據通過控制層返回給視圖層展示給用戶【叭在MVC 模式原理圖中，模型層包括了兩個子層，分別為Service層和Dao層，Service層用于接收前端請求，Dao層用于數據庫連接。一般地，開發人員可根據項目實際需求，搭建合適的項目開發環境，可以在三層模式的基礎上擴展為四層或五層，降低各間的耦合性。

圖2-3 MVC模式模型圖

2.1.5通用訪問控制策略

訪問控制是指授權特定的用戶訪問特定的資源⑴］。訪問控制經歷了以下幾個階段。

自主訪問控制(Discretionary Access Control, DAC)技術，是一種根據對象或所屬組的身份標識來限定對客體的訪問的方法［12］,可以通過對象的屬性來規定對該對象的保護方式，但這種訪問控制策略具有不利于全局訪問等弊端。

強制訪問控制(Mandatory Access Control, MAC)技術，它是指通過操作系統限制主體或發起者訪問資源或具備對某個對象或目標執行某種類型操作的能力，任何對象上的任何操作都將根據一組授權規則(aka策略)進行測試，以確定是否允許操作。在傳統上，MAC控制一直與多級安全(MLS)和專門的軍事系統緊密聯系在一起，所以這種訪問策略適用于多層次安全級別的軍事應用，但它存在授權可管理性弱的缺點。

基于角色的訪問控制(Role-Based Access Control, RBAC)技術，是基于用戶、角色和權限的訪問策略【⑸。這是一種被廣泛使用的授權機制，其核心思想是將一個執行操作集定義為權限，并將權限分配給角色，通過賦予用戶角色而使其具有執行資源的權限。在4.2.1小節中詳細介紹該策略。

基于任務的訪問控制（Task-Based Access Control, TBAC）技術，常用于基于工作流的業務中，是一種基于授權節點的訪問方式"］。核心概念包括授權節點、授權結構體等，該訪問控制在粒度上比RBAC更加細致，可以彌補RBAC 中無法滿足同一角色不同訪問權限的不足。

除此之外，還有基于用戶和基于用戶組的訪問控制策略。每種訪問控制策略的粒度、適用場景、授權客體、授權主體都略有不同，在方案選型時，需要根據系統實際需求來確定方案。針對系統需求，本人釆用了一種基于多粒度組合的訪問控制方案。

2.1.6通用加密算法

隨著密碼學技術的快速發展，目前存在對稱、哈希和非對稱結構的三類加密算法，下面詳細介紹三類算法的適用場景。

對稱加密算法使用同一密鑰對敏感數據實現明文和暗文的計算轉換［均。該算法具有加解密過程速度快和難破解性（破解難度與密鑰長度有關），但其密碼管理比較復雜。若用戶量比較大的情況下，使用的密鑰會較多，復雜度在0（22）的級別，密鑰的管理就比較復雜了。密鑰的安全性決定了對稱加密算法的安全性，所以如果使用固定的加密密鑰就存在密鑰泄露、數據信息泄露的問題。對稱加密算法對比如下表2-2所示。

表2-2對稱加密算法對比

名稱密鑰長度（位）運算速度安全性資源消耗

DES 56 較快低中

3DES 112/168 慢中高

AES 12^19^/256 快高低

非對稱加密是指使用不同的密鑰實現數據的明文和暗文的轉換，故加密過程至少需要兩個密鑰。兩個用戶相互傳遞加密數據時，一方使用對方的公鑰加密，則對方可以用自己的私鑰進行解密［閔。非對稱加密算法在密鑰的管理上比較方便，但非對稱加密算法在加解密效率上要遠低于對稱加密算法。非對稱加密算法的私鑰還可用于驗證信息來源，并作為發送者已經發送該信息的證據。各類非對稱加密算法的對比如下表2-3所示。

表2-3非對稱加密算法對比

名稱j成熟度（取決于密鑰長度）（安全性運算速度|資源消耗

RSA |高［高慢丨高

DSA |高高慢 |用于數字簽名

ECC |低；高快 |低

Hash算法是一種基于哈希表的一種單向算法，單向是指Hash算法加密后的數據不能被解密，常用于口令存儲和信息完整性校驗中。常見的Hash算法包括 MD系列和SHA系列等。SHA系列算法安全性高但計算速率慢；MD系列算法安全性中等但計算速率快。

綜上所述，對稱加密算法具有密鑰難管理、適用于內部系統、安全性中等、加密速度較快，并且適合大數據量的加解密處理的特點；非對稱加密算法具有密鑰易管理、安全性高、加密效率低，適用于小數據量加解密處理的特點。考慮到航天所設備信息管理屬于企業內韶系統、且數據量中等、數據加工效率高的需求, 在系統中使用AES及SHA-1算法對數據加工處理。

2.2設備信息管理系統需求分析

該小節介紹系統的需求分析，需求分析主要論述了航天研究所使用傳統模式管理設備時包含了哪些日常管理業務。通過對“線下”業務的分析確定“線上” 業務的建設目標。本小節主要介紹核心業務需求分析，由于系統建設是本人與實驗室另一同學共同完成，所以在本章節介紹了整個系統的核心業務，而在第三章僅介紹本人負責的業務模塊。

2.2.1核心業務需求分析

課題研究目標就是為航天研究所實現設備儀器類信息化平臺上線管理，實現設備維護、辦公營具、房產等資產信息化平臺上線管理。軟件上線后可以滿足航天所設備儀器類網絡化、信息化管理，建立所各個部門共同使用的設備軟件門戶平臺，實現從購置設備、到貨驗收、入賬登記、設備變動、使用部門二級臺賬建立、維護維修及辦公營具、科研生產房產等非設備儀器類資產的信息化管理。按照各職能審批權限加入審批流程及臺賬等相關信息，設備儀器供應商信息統計管理、網上審批等全過程網絡化管理，避免了繼續使用電子表格統計設備的原始方法，提高設備儀器管控過程中的時效性，使之設備的管控更加先進和有效。圖 2-4展示了業務用例圖概況。

圖2-4業務需求總用例圖

2.2.2.1登錄管理

設備信息管理系統是部署在航天所內網中的，內網的特性是能夠為所內的所有資源提供一道天然的保護屏障。目前航天所的員工登錄終端設備需要通過USB Key認證的方式來進行將用戶身份認證，所有的終端設備都加入到航天所的域林中，所有的用戶都被管理員統一管理。所以USB Key和AD域是保護設備信息管理系統的第一個屏障，但是若惡意用戶通過惡劣手段登錄到終端機器上，對系統安全性造成了威脅。簡單的賬戶密碼不能滿足系統安全性需求，需要將AD域與系統賬戶結合使用，驗證用戶信息的一致性。從AD域中獲取終端用戶的信息, 將該用戶的信息與系統中賬戶信息進行一致性校驗，不同校驗結果有不同的響應內容。

2.2.22組織權限管理

在論文研究背景及研究內容中提及了 BPM業務流程管理的概念，業務流程管理中體現的核心意義就是通過不同級別的人員審核由普通人員提出的申請，決定普通人員提出的申請是否通過，其目的是實現對企業業務更加嚴格的執行和監督。為了實現各級人員的區分，需要為系統設計用戶角色，達到分權限管理的目的。組織權限管理包括用戶、角色、權限、權限分配等的管理。除了提供權限網中的各個必要元素的維護管理功能外，還要提供建立對應關系的服務功能。

2.2.2.2前期管理

一、供應商管理

1.業務需求描述

研究所設備資產比較特殊，設備購置需從已認證的供應商購置。如果用戶為了個人利益刪除或者修改供應商信息，那么會對所內的設備質量或經濟造成威脅，故不同角色需要授予不同管理權限。普通用戶可查詢供應商信息，若新增信息，則需要經過上級領導的審批；設備儀器主管具有查看、錄入、編輯供應商數據的權限。當普通用戶添加供應商信息時，需要執行供應商新增審批流程，由部門領導和設備儀器主管來審批。用例圖如圖2-5所示。

2.主要角色

根據上述需求描述，供應商管理流程中涉及到普通用戶、部門領導、設備儀器主管三種角色。

設備儀器主管

圖2-5供應商管理用例圖

二、采購管理

1.業務需求描述

采購模塊提供了建立設備采購申請流程的服務。該業務功能是為了規范化采購過程，避免各部門隨意購設備，造成資源和經費的浪費。下面對采購審批的業務需求做詳細論述。

（1）結合設備儀器管理辦法，由設備儀器購置部門申請人登錄賬戶、設置密碼門戶權限，填寫電子版購置申請單，在線審批，審批權限按照職能劃分進行在線審批。

（2）購置申請單編號應自動生成（軍品GZJ20170001,民品GZM20170001 生成后不能重復，年份需要根據實際年份自動改變）。

（3）購置的設備儀器按照資產類別進行進賬統計，例如設備類進入設備類總臺賬，儀器類進入儀器類總臺賬，按照資產類別進行部門審批權限，例如設備儀器購置審批權限為安全技術處，空調、辦公營具為行政保障處。

（4）如購置的是易耗類物資，購置申請單上應有易耗類物資選項。易耗類物資是指使用過程中容易損壞、使用年限少于一年的設備儀器，或科研生產過程中的輔助物資和工具。其中也包括一些靶場用的高值易耗類。由部門申請人填寫選擇，最終是否是易耗類由設備儀器主管確認。易耗類不需要建立臺賬，但購置仍然需要走審批流程。

（5）單臺設備儀器價格在20萬元及以上（含安裝費、基礎建設費）的設備, 在申請人填寫完申請單后還需要針對價格不小于20萬的設備填寫《設備儀器購置論證報告》，論證報告中主要填寫設備主要功能技術指標、必要性、適用性、進度及保障要求等，可附加頁，按照制度走審批流程。申請人將購置申請表和論證報告一起提交至上級領導，上級領導需要查看購置申請表和論證報告后決定是否同意通過。

（6）購置申請時必須只限預算內申請，如價格超出預算范圍，設備儀器主管部門不予網上審批。預算外購置申請由所領導批復后再執行網上流程審批。

（7）審批權限：購置申請部門申請人填寫后由購置部門管理員、購置部門一把手審批、保密處、設備對應的設備儀器主管、主管所領導審批，最后由安全技術處主管查看后流程結束。設備儀器主管審批時只能審批設備儀器主管負責的設備類型，在設備儀器主管審批之前需要對表單數據進行拆分,然后并行發送給相應的設^•儀器主管，當所有的設備儀器主管審批完后，需要將數據整合到一起, 繼續進行下一角色的審批。

（8）能力建設過程中的購置的固定資產，通過現場轉股確認，按照安全技術處提供的電子表格自動轉入信息系統內。現場確認簽署完整后，將電子版本數據包直接進入系統內，此項操作權限為設備儀器主管。

（9）購置原值應包含設備單價、運輸費、檢驗費等全部支出。應與設備價款相加一同列入，總和為設備原值（入賬單里需要填寫）。購置過程中產生的支出在驗收入賬流程中填寫。

（10）采購流程走完之后，需要打印出申請表單內容，存檔保留。然后需要將購置申請單中的內容自動推送到財務處。

2.主要角色

設備采購審批流程中涉及普通用戶、部門管理員、部門領導、安全保密管理員、設備儀器主管、主管所領導、安全技術處主管角色。

三、到貨驗收和設備儀器入賬管理

1.業務需求描述

到貨驗收業務是對購置的設備進行驗收操作的管理，采購設備的用戶在設備到貨后驗收設備，并發起驗收審批流程，由上級領導對驗收情況進行審批。驗收完成后自動發起入賬，且入賬信息是從驗收單過來的，所以把驗收和入賬的業務需求放在一起論述。

（1）設備到貨后，使用部門應報請設備儀器主管部門組織相關部門現場驗收，驗收合格后，使用部門填寫到貨驗收單并發起網上驗收審批流程，經過逐層審批，評定驗收是否通過，簽字部門有審批和退回的權限。該流程需要提供驗收單打印和入賬單打印的功能，且只能在流程結束后打印表單信息。

驗收流程結束后能夠自動發起入賬流程，驗收單中的信息能夠自動帶入入賬單并根據設備類型流轉到不同的角色進行審批，驗收單中填寫的隨機資料名稱能夠自動生成歸檔清單，歸檔清單可以進行修改。在審批流程中如果驗收入賬需要保密處的審批，則還需要在質量保障處審批后，走保密處審批。是否需要保密處審批需要根據驗收設備信息是否涉密決定。

（2）設備儀器入賬單審批完成后，自動轉入所對應總臺賬及使用部門的二級臺賬管理查詢庫里，注意，入賬單上需要增加選項，由安全技術處主管選擇是設備類還是儀器類。

（3）設備儀器入賬后按照航動臺賬、航化臺賬、時翼臺賬、其他臺賬入賬后，與財務處入賬人員有權限點擊查看。

（4）到貨驗收單需要增加一欄歸檔清單，由使用部門填寫，情報檔案中心負責審核確認。

（5）入賬分為驗收后入賬和直接入賬，根據航天所實際管理需求，信息化中心購置的設備可直接入賬，其他部門購置的設備需要經過審批，所以入賬入口需要有兩個，一個是針對信息化中心，一個是針對非信息化中心。

（6）設備使用人在填寫驗收申請單時，供應商是可以改變的，如果在提交表單信息時檢查出供應商信息沒有在供應商名冊中，需要自動開啟新增供應商子流程，將供應商錄入到數據庫后再繼續驗收流程。

2.主要角色

根據對驗收入賬審批需求的分析，流程主要角色包括普通用戶、檔案驗收員、質量驗收員、保密處領導、設備儀器主管、安全技術處主管。

四、其他資產入賬管理

1.業務需求描述

其他資產入賬是為了將不屬于任何設備類型的設備錄入臺賬。不同于驗收入賬流程和直接入賬流程，其他資產入賬的設備信息是由用戶手動填寫的，而不是從系統中自動加載進來的。設備使用人填寫其他資產入賬審批表并提交至部門領導審批，部門領導審批通過后提交至設備儀器主管審批，設備儀器主管審批通過后提交至安全技術處主管審批，安全技術處主管審批通過后，流程結束。審批流程中，任意一個審批節點沒有通過都需要將表單回退至申請人，由申請人重新提出申請。

2.主要角色

根據對其他資產入賬審批需求的分析，流程主要角色包括普通用戶、部門領導、設備儀器主管、安全技術處主管。

2.2.2.3資產管理

一、資產調撥

1.業務需求描述

資產調撥業務主要是將設備資產從某部門某使用人的名下挑撥到其他部門其他使用人下，如同資產使用人的交接審批。調撥完成后臺賬信息中的使用人、責任人等信息自動發生變更，并將設備調撥單推送到財務處。下面對該業務的需求做詳細論述。

（1）按照調撥審批流程，創建設備儀器調撥申請門戶，調撥申請使用部門申請人提出申請，點擊調撥申請后系統自動生成《設備儀器調撥通知單》，在表格中空白處詳細填寫后，選擇推送到原部門領導審批后，由挑撥后使用人接收信息并填寫此表審批，然后依次由調撥后接收部門的領導、設備儀器主管、設備儀器主管部門領導、主管所領導及安全技術處主管審批，直至流程結束。

（2）調撥審批流程結束后，根據調撥通知單中的固定資產編號自動在總賬及二級臺賬更換使用部門。

2.主要角色

根據上述業務需求描述，調撥審批流程主要角色包括普通用戶、部門領導（原使用部門及挑撥后使用部門）、設備儀器主管、設備儀器主管領導、所領導、安全技術處主管。

二、資產封存

1.業務需求描述

資產封存業務是將長期時間內不再使用的設備資源進行封存入庫，保證資源不被浪費，避免造成資源的大量損耗。資產封存業務中重要的是設置封存期限，到期后，需要提醒相關人員封存到期了。下面詳細論述閑置封存業務需求。

（1）按照閑置封存轉讓審批流程，創建設備儀器閑置封存申請門戶，申請由使用部門申請人提出申請，點擊閑置封存申請后系統自動生成《設備儀器閑置封存審批表》，申請人在填寫完申請表格提交給部門領導，部門領導審批閑置封存申請表，并在審批通過后依次提交至科研生產業務管理部門領導、設備儀器主管、主管所領導、安全技術處主管審批，直至流程結束。

（2）閑置封存審批流程結束后，根據設備儀器的固定資產編號，將該設備在總賬里的狀態更新為閑置封存，同時將該設備信息添加至設備儀器閑置封存臺賬明細表里。

（3）流程結束后，系統自動通知財務處入行人員查看。

（4）設備封存期限到期后，需要自動給使用人及設備儀器主管發起到期提醒，由使用人繼續選擇封存還是啟用，繼續封存則須填寫封存期限，啟用則需要自動發起設備啟用流程。

2.主要角色

根據上述業務需求的描述，設備閑置封存業務涉及到的主要角色包括普通用戶、部門領導、科研生產業務部門領導、設備儀器主管、主管所領導、安全技術處主管。

三、資產啟用

1.業務需求描述

資產啟用業務是對已經閑置封存的資產啟用。資產封存有一定的封存期限，當在封存期限內向啟用資產，需要經過資產啟用流程審批后，將閑置資產投入使用。下面詳細論述資產啟用的詳細需求。

（1）按照設備儀器啟用審批流程，創建設備儀器啟用申請門戶，申請由使用部門申請人提出申請，點擊設備儀器啟用申請后軟件系統自動生成《設備儀器啟用審批表》，申請人在表格中空白處詳細填寫后，推送到部門領導審批，部門領導登錄系統并審批，審批通過后提交審批表至設備儀器主管，設備儀器主管登錄系統后，需要填寫實際啟用日期并進行審批，審批通過后提交信息至所領導，然后依次由所領導、安全技術處主管進行審批，審批通過則流程結束，資產啟用完成。同樣地，如果在審批過程中任何一個審批節點不通過都需要將申請單回退至第一節點的申請人。

（2）啟用審批流程結束后，根據設備儀器的固定資產編號，自動將總賬該設備的狀態改為在用狀態，同時把設備儀器閑置封存臺賬明細表里的啟用設備刪除。

（3）流程結束后，系統自動通知財務處入賬人員查看。

2.主要角色

根據以上業務需求描述，設備啟用審批過程中包括的主要角色有普通用戶、部門領導、設備儀器主管人員、所領導及安全技術處主管。

四、資產報廢

1.業務需求描述

設備是有使用壽命的，當使用時間較長或者其他原因導致設備能繼續工作，需要進行資產報廢審批，經由上級領導部門的審核確認，將設備列入報廢行列。需要經過審批的原因就是避免員工隨意報廢設備，造成資源的浪費，經濟的損失。下面對資產報廢業務需求進行詳細的論述。

（1）按照航天設備儀器管理辦法中報廢審批流程，建立設備儀器報廢申請門戶，報廢申請由使用部門提出申請，申請人在填寫申請表后，依次經過部門領導、部門分管領導、科研生產管理領導、設備儀器主管、所領導、安全技術處主管審批，審批通過后流程結束。

（2）不同類型的設備，需要由不同的設備儀器主管負責審批。特種設備由安全^^術處主管填寫鑒定意見、運輸工具由辦公室主管填寫鑒定意見、計量類設備儀器由質量保障處主管填寫鑒定意見、信息系統設備由信息中心填寫鑒定意見、其他設備由使用部門領導或總工填寫鑒定意見。

（3）設備儀器報廢申請單上要增加是否接入涉密網絡選項，若“是”則推送至保密處；若“不是”則流程推送至設備儀器主管繼續審批。

（4）報廢審批流程結束后，根據設備儀器的固定資產編號自動在總賬及使用部門二級臺賬里刪除，同時進入設備儀器報廢臺賬明細表里（設備儀器報廢臺賬）。已經報廢的資產編號不再二次使用，系統永久提示。

（5）當原值在10萬元以上（含10萬元）設備儀器報廢時，流程按照航天所要求需要走紙質簽字后報院級審批，此處設備儀器資產主管部門根據紙質批復對總賬更改。在臺賬中將報廢設備的狀態修改為報廢，并將報廢設備信息錄入到設備儀器報廢臺賬中。

（6）處置結果（含處置收入、處置支出）由處置部門填寫后流程自動流轉到財務處，財務處入賬人員有權限點擊查看，其中資產凈值、使用年限由財務入賬人員填寫完善后系統自動保存。

2.主要角色

根據對業務需求的論述，設備報廢流程涉及到的主要角色包括普通用戶、部門領導、部門分管領導、科研生產管理領導、保密處領導、設備儀器主管、所領導、安全技術處主管。

2.2.2.4特種設備管理

特種設備管理業務主要是對特種設備下的各子類型設備的檢定時間進行管理，能夠根據上次檢查時間和有效期自動得出下次檢查時間。特種設備屬于研究所內大型貴重資產，如果不做好周期性的檢查，一旦發生危險，將會帶來不可預想的后果。安全技術處主管具有查看、導入導出、編輯、查詢、打印標簽等權限; 部門系統管理員具有查看、查詢本部門臺賬，編輯上次鑒定時間、有效期的權限; 普通用戶具有査看、查詢責任人為本人的臺賬，編輯上次檢定時間、有效期的權限。

2.2.2.5車輛管理

車輛屬于交通運輸設備，無論是場內的貨物運輸設備還是員工班車，都需要定期檢查車輛運作手正常，避免在運輸過程中出現失控或無法運作的情況，也避免發生危害人員安全及設備質量的問題。車輛管理也主要包括車輛檢定周期的管理，通過上次的檢驗時間和有效期能夠自動計算出下次檢驗的時間。辦公室主管具有導入導出、查詢、打印標簽等權限；部門系統管理員具有查看、查詢本部門臺賬、編輯上次鑒定時間、有效期的權限；普通用戶具有查看、查詢責任人為本人的臺賬，編輯上次檢定時間、有效期的權限。

2.2.2.6預報管理

預報管理是為了給用戶發出預警提示。鍋爐和車輛管理中都有下次檢定時間，我們可以在預報管理中設置提前多少天提醒用戶下次檢定時間。該功能提醒用戶對特種設備和車輛進行檢定，不需要用戶自己去計算還有多久到下次檢定時間。預警可通過消息提醒和郵件提供服務。用戶可以自定義提前預警天數和預警方式。設備儀器主管具有錄入、編輯、保存等權限。

2.2.2.7基礎數據管理

基礎數據是流程中的業務模塊用到的基礎數據，主要包括資產類型、試驗臺、檢查周期、使用狀態、計量儀器分類代碼庫及設備類型與設備主管對照數據。維護基礎數據將為業務模塊提供數據服務。下面對每個基礎數據管理需求做詳細論述。

1•資產管理。資產管理主要是維護設備類型數據，設備類型分為三級目錄，特種設備和信息化設備均有下級子目錄。設備種類和數量較多，通過該模塊設備儀器主管能夠手動維護資產分類，添加資產分類中的具體類別，提高管理效率。

2.試驗臺管理。在設備購置時，用戶需要選擇所購置的設備是否是試驗臺以及屬于哪一個試驗臺，該模塊為設備采購模塊服務。

3•檢定周期管理。檢定周期是指特種設備和車輛的檢查周期。檢定周期維護權限賦予設備儀器主管，并為預報、維修維護模塊服務。

4•使用狀態管理。使用狀態是指設備當前的狀態。入賬后的狀態為可用，領用后的狀態為在用，閑置后的狀態為閑置封存，啟用后的狀態為可用，維修中的狀態為設備維修中，報廢后的狀態為報廢。

5.計量器具分類代碼庫管理。在設備入賬時，計量儀器類需要生成分類代碼，便于按照最小粒度管理。

6•設備類型與設備主管對照表管理。在流程執行過程中，根據設備類型找到相應的設備主管角色來完成審核。

2.2.2 8臺賬管理

1.業務需求描述

由于研究所內設備種類多、設備數量大，設備臺賬的建立方便用戶對復雜的設備數據進行管理。臺賬類別包括航動、航化、時翼、其他資產臺賬四類。每種臺賬里的資產類別包括設備類、儀器類、房產類、辦公營具類和車輛，這些類別屬于父類別，在臺賬管理時，需要將大類別細分為多個小類別。儀器類里按照屬性劃分包括信息化設備、通用儀器、計量器具。車輛類、房產類和辦公營具類沒有小類別。

2.主要角色

涉及臺賬管理業務的角色及角色權限如表2-3所示。

表2-3角色與臺賬管理權限對照表

NO 角色權限

1 普通用戶查看個人相關的臺賬、發起變更流程

2 安全技術處主管查看所有設備、數據導入導出、增刪改查、上傳照片及打印設備標簽等 —j

3 特種設備主管查看特種設備、數據導入導出、增刪改查、上傳照片及

打印設備標簽等 __ __

4 信息化主管查看信息化設備、數據導入導出、增刪改查、上傳照片及打印標簽等

5 計量器具主管查看計量儀器設備、數據導入導出、增刪改查、上傳照片及打印標簽等

6 辦公室主管查看車輛設備、數據導入導出、增刪改查、上傳照片及打印標簽等 .

7 行政處主管查看空調、電梯設備、數據導入導出、增刪改查、上傳照片及打印標簽等

8 部門管理員查看本部門設備、發起變更流程、上傳照片及打印標簽等_ —

9 財政入賬管理員按條件查詢臺賬信息

2.2.2.9在線學習

由于航天所設備的復雜性，新入職的員工對設備使用及設備管理等操作不熟悉，為了給新員工提供自學的服務，有必要設計在線學習的模塊。課件上傳是為了方便員工在線學習，課件上傳后，上傳者可對課件進行查詢、預覽和下載。課件內容可以為OFFICE文檔、PDF及視頻；學習資源推送實現了培訓負責人或部門領導定時向需要學習的學員推送資源的功能，學員在接收學習資源后，在其個人學習界面會增加學習任務；個人學習界面包括課程收藏和學習任務，課程收藏是學員根據個人喜好收藏的課程，學習任務是學員從領導那里接收到的學習內容；課程在線學習給員工提供了在線觀看視頻的功能，點擊進入后，系統開始計時，關閉后，系統結束計時。

2.2.2.10考試管理

為了考查員工對學習內容的掌握程度，也為了提高員工對設備使用及管理的水平，考試管理模塊提供了員工技能水平檢測功能。試題管理和試卷管理都是對考查內容管理維護，在線考試是為員工提供了在線考試的子系統，具有展示試卷、答題、判卷等功能。

2.2.2.11其他管理需求

1.信息化設備、空調、電梯、車輛、辦公營具的審批流程同上，按照分管職能機關進行審批，并形成臺賬，與現行實際機關職能分工一致。

2.按照設備儀器管理辦法，每年應進行設備盤點，如盤盈出現新增設備儀器，除網上審批購置的設備儀器外，盤盈的設備儀器需要填寫說明上報至安全技術處，安全技術處按照真實盤點情況直接錄入其他資產臺賬，同時錄入使用部門其他資產臺賬，其表格與設備臺賬一致，多加一欄情況說明。

3.每種設備類型入臺賬時，需要錄入的屬性信息是不同的，每種類型錄入臺賬的信息如下表2-4所示。

表2-4各設備類型對應的入賬字段信息

分組設備類型入賬字段

第一組通用設備專用測試設備通用儀器信息化設備電梯空調

起重機械場內專用機動車資產名稱、發票號、合同額、保修截止日期、型號、規格、用途、品牌、銷售供應商、生產廠家、國別、安裝調試費用、原值、使用部門、安裝地點、啟用年月、技術指標、使用狀態、責任人、使用人、出廠編號、備注等 1

第二組鍋爐、壓力管道、

壓力容器同第一組，另補充體積、壓力、設備的適用介質

第三組安全附件

（續上表）

分組設備類型入賬字段

:作壓力、工作溫度、工作介質 __ _ __ _

第四組計量儀器同第一組，另補充精度、部門、負責人、日期、檢定周期、校驗結果、校驗屬性、類別ABC、證書編號、委托單號

第五組車輛 1同第一組，另補充車牌號、發動機號、購買日期

2.2.2必要性分析

該研究所設備主管部門包括安全技術處、質量保障處、信息中心和辦公室等, 部門之間有頻繁的業務交流。多部門的管理工作比較分散，缺少設備儀器的綜合管理平臺，所有管理工作都停留在紙質階段，缺乏信息化手段。為此，研究所發布了關于研究所設備管理整改辦法，為改變研究所設備管理工作的傳統模式，需要搭建設備信息化管理平臺，完成電子化管理。

2.2.3可行性分析

大多數功能模塊都是基于業務流驅動的流程模塊，且功能屬于日常設備信息管理功能，BPM技術及信息化系統建設技術發展較為成熟，所以在技術上是可行的。系統所涉及的所有功能模塊均符合社會價值觀、道德規范及法律法規，信息化建設也有利于我國國有企業的發展，所以在社會性及價值性上是可行的。

2.3安全機制需求分析

航天所屬于典型的軍民融合的企業，企業設備信息包含秘密信息，在建設設備信息管理系統時需要按照國家要求、企業要求建設一套完備的安全機制，保證系統安全。設計安全策略時要遵循航天所的安全等級的要求，結合航天所目前存在的信息安全技術及安全措施，將安全機制落實到系統上來。本小節介紹了安全技術體系中系統方面的核心需求，同時介紹了安全機制的必要性和可行性。

2.3.1業務需求分析

信息管理系統的安全技術體系如圖2-6所示。系統級防護，主要包含認證授權、數據加密等；流量級檢測主要包含入侵、邊界、病毒檢測等；人員級響應，主要包括調査取證、事件處理及設備聯動；數據級恢復，主要包括備份和恢復。航天設備信息管理系統安全機制的建設主要以系統級防護為主，數據級恢復為輔。系統防護中的四個組成部分從技術角度分析，可以分別解釋為密級標識、身份認證、訪問控制和安全審計，另外還包括對系統操作的日志進行收集分析，統計不同審計級別的系統操作日志。人員是系統的面向對象，人員在系統上進行的一切行為就是操作，操作行為的收集就是我們需要的數據源，數據源的分析及系統的安全防御就是通過技術來實現的。下面將詳細描述系統級防護中的四種機

圖2-6安全保密技術體系圖

2.3.2.1密級標識

密級標識，是敏感信息實體的秘密等級標識，是分級體系中關于如何規劃各個安全域之間的信息流量以及信息訪問管控的重要內容I"】。國家在分級保護要求中提出的重要概念之一就是密級標識，在這個標準中提出密級標識是代表信息秘密等級的數字化信息，密級標識與數據實體不可分離、禁止修改I】*】。密級標識是安全研究上的突出成果，將會帶來信息安全領域的理論、技術及實踐上的探索，也將會引來大量的市場需求。隨著我國密碼學技術、密級標識理論和技術的不斷發展，信息實體及其密級標識的應用產品的發展方向和驅動力都掌握在我國手中。

航天設備信息管理系統是基于流程驅動的管理系統，系統中的人員和數據都需要密級標識，密級包括非密、秘密、機密。根據所內員工安全責任意識及職級的不同，員工的密級不同。為了明確劃分每個員工的責任，需要給所有員工設置密級。非密用戶只能訪問允許訪問范圍內的非密數據，秘密用戶可以訪問允許訪問范圍內的秘密數據和非密數據，機密用戶可以訪問允許訪問范圍內的機密數據、秘密數據和非密數據，如圖2-7所示。為了避免員工密級泄露，也為了避免惡意用戶修改員工的密級，需要對員工密級進行加密。數據密級標識作用于敏感信息、表單信息和流程信息。表單是綁定在流程節點上的，每個節點的辦理人不同且辦理人密級不同，則節點辦理人對表單的訪問權限就不同。流程的密級標識主要用于訪問控制，低密級用戶無法參與到高密級流程實例中。對于數據的秘密標識也是需要進行加密的，加密方式的設計與用戶的密級標識一致，將在數據加密小節中介紹。

非密

圖2-7密級標識在訪問控制中的作用

2.3.2.2數據加密

設備信息系統中的對密級標識和敏感數據進行加密。這里說的加密主要指加密存儲，秘密等級主要包括機密、秘密、非密，標識字段屬于簡短信息，即需要加密的內容信息量比較少，且只需要加密不需要解密，所以采用不可逆的哈希算法進行加密即可。對于業務中敏感數據，需提供加密和解密處理程序。目前有很多加密算法，不同加密算法適用于不同業務場景，數據加密設計在第四章安全設計篇幅中詳細論述。另外，通過Excel、PDF、JPG、Word等導出文件時，需要對敏感數據加密，避免敏感信息脫離系統保護后遭到惡意泄露。

2.3.2.3身份認證

在系統防御機制中，用戶身份認證屬于進入系統的第一道關卡，認證成功的用戶才有權限進入系統。在設計系統認證功能時需結合航天所環境的特殊性。航天所內網環境及物理安全基礎給所內信息化資源提供了第一道屏障。內網環境及限制軟件使用也使得身份認證技術有約束性。目前，所內所有員工登錄終端機器都必須使用USB Key身份認證的方式，如果在登錄系統時再次使用USB Key進行認證，不利于所內員工日常工作的進行。綜合考慮，設備信息管理系統采用復雜口令及AD域認證的方式來進行身份認證。AD域認證的方式可以提供免登錄的服務，節省時間。

信息管理類系統普遍采用口令認證方式，為了提高系統擴展性，系統保留了此認證方式，并設計了復雜口令設計策略，提高系統安全性。該方式主要用于自動登錄失敗的情況，其作為備用方式，需要管理員權限啟動。

2.3.2.4訪問控制

在眾多安全策略中，訪問控制起到了支撐系統安全的核心作用。該機制通過制定策略來指定某些用戶管理某些資源。不過航天所設備管理系統中的訪問策略是比較復雜的，因為企業性質特殊性及設備信息特殊性，需要對不同粒度的組織進行訪問控制。例如，指定某一 IP的用戶訪問某些資源、指定某一部門的用戶訪問某些資源、指定某一角色的用戶訪問某些資源、指定某一資源由哪些用戶可以訪問等。

下面介紹流程中涉及到的訪問控制場景。低于流程密級的所有用戶都不能參與流程的審批，此為密級控制策略；流程實例節點辦理者角色不同，此為角色訪問控制策略；指定某一任務節點由某人辦理，這是指定資源由某一用戶訪問的控制策略；指定某些設備資源只能由某些人訪問，這是組用戶訪問控制策略；某些資源僅由某一 IP的用戶登錄并訪問，例如管理員的權限相對較高，則看到的資源信息就比較多，可以通過指定IP的方式實現訪問控制。另外頁面訪問控制還包括禁止查看網頁源碼、打印、復制網頁內容和防盜鏈技術等。

2.3.2.5安全審計

涉密應用系統應對系統管理員、保密管理員、安全審計員、普通用戶等的所有操作及告警信息進行審計［19】。應根據實現應用系統可能存在的脆弱點和應用系統運行性能、安全需求來確定安全審計的范圍。審計日志應包括安全事件審查及責任人追查的重要信息。系統操作日志需要包括：

（1）涉密應用系統的啟動和關閉；

（2）涉密應用系統功能模塊的啟用和關閉；

（3）系統內用戶增加、刪除；

（4）用戶權限的更改；

（5）三員操作痕跡；

（6）用戶的違規操作行為；

（7）身份認證相關事件；

（8）訪問控制相關事件；

（9）涉密數據的輸入輸出操作；

（10）涉密數據的其他操作；

（11）其他可審計事件。

同時，保密管理員和安全審計員的審計操作也應該記錄下來。審計記錄應包括以下內容：時間、主體（操作人姓名、登錄名）、地點（IP、MAC）、對象類型（包括文檔類型、配置類型和用戶類型）、客體（對象名稱、對象密級）和結果（成功或失敗）、操作模塊（系統功能模塊）、操作的安全級別（分為信息、警告、錯誤三個級別）。其中錄入信息為信息級別，修改和刪除為警告級別，用戶登錄失敗為錯誤級別。審計記錄應具有根據事件發生的時間、類型、主體等屬性進行查詢的功能，以及對系統內產生的審計記錄進行集中瀏覽、統計和生成報告的功能。審計日志提供足夠多的信息目的是保留操作發生的時間、來源和結果。

2.S.2.6系統監控

系統監控主要是對系統所在服務器的CPU消耗情況、內存使用情況、系統并發用戶量等進行監控，確保系統正常穩定運行。系統監控的功能主要是服務于后臺系統中，系統管理員可以通過登錄后臺系統監控當前在線用戶數量，也可以通過查詢系統運行日志分析系統的穩定性，比較在線用戶數較多和在線用戶數較少的情況下，對操作系統資源的消耗情況，以確保系統在高并發情況下，能夠承擔一定的訪問壓力。系統監控也會在系統灰度上線時，作為上線后的臨時監控工具，測試系統是否穩定。系統的瓶頸一般是并發訪問及數據庫讀寫兩個方面，在建設系統時需要考慮系統使用人數及數據量的大小，確保系統的穩定性和健壯性。

2.3.2必要性分析

由于紙質化管理模式不利于企業的發展，無法激發企業發展的核心動力，所以，系統的建設對企業的發展是非常必要的；企業的性質為軍民融合的企業，具有涉密性，為了保護數據安全，建設系統安全機制是必要的。

2.3.3可行性分析

通過對安全機制的業務需求分析，需要用到的技術都是很成熟的，所以在技術上是可行的；安全機制涉及的技術均可實現，且能夠滿足設備信息管理系統的安全需求，所以安全機制的建設是可行的。

2.4本章小結

本章主要介紹了三部分內容，首先是對系統建設用到的技術進行介紹，分析了通用技術的優勢和特點；其次是介紹系統業務需求，航天設備管理不同于普通企業的信息化管理方式，突出了建設具有航天特色的設備信息管理系統的重要意義；最后介紹了系統級的安全技術體系，確保設備信息管理系統在完成日常業務的同時，能夠保護敏感信息的安全。

第三章航天設備信息管理系統的設計與實現

該章節主要介紹航天設備系統的功能模塊設計、數據庫設計及系統實現內容。首先，本章介紹了設備信息管理系統的概要、詳細設計，分功能模塊進行論述，并通過流程圖詳細介紹復雜功能的邏輯流。其次，介紹了數據庫關系圖和數據庫表的設計。最后，介紹了系統功能模塊的實現，包括流程建模、表單模型及事件觸發類的實現。

3.1設備信息管理系統的設計

3.1.1系統設計原則

系統設計包括概要設計和詳細設計，在設計功能模塊時需要以用戶為中心，不僅要實現基本功能，還要優化用戶體驗。系統設計原則如下：

1.正確性。系統要給用戶提供正常使用的功能，這是最基本的要求；

2.可靠性。系統要能保證長時間運行時的可靠性，不能出現嚴重BUG,導致系統死機；

3•易用性。系統界面在設計時需要考慮用戶日常操作習慣、不同計算機操作水平，增強系統易用性。

4.可擴展性。業務功能不是一成不變的，系統在構建時需要確保其功能的易擴展性，提高代碼靈活性。

5.安全性。系統中包含用戶敏感數據，需要充分考慮系統可能受到的攻擊，并建設安全機制，維護系統安全。

3.1.2系統概要設計

3.1.2.1系統架構設計

本節主要講述設備信息管理的架構設計。本課題研究的設備信息管理系統架構主要分成四層，自底向上主要包括數據層、應用支撐層、應用層和用戶層。本系統的系統架構圖如圖3-1所示。數據庫層將系統應用支撐層的數據持久化到硬盤中；應用支撐層是連接應用層和數據庫層的中間支撐層，應用層功能的實現是基于應用支撐層的，應用支撐層主要包括用戶、角色、用戶角色分配、審計及流程管理等；應用層主要為用戶層提供支持，該層的作用類似于MVC

模式中的業務邏輯層，負責控制業務功能的流轉，也負責將數據持久層的數據傳輸到用戶層，展現給用戶；用戶層類似于MVC模式中的視圖層，即直接與用戶打交道的一層，將應用層的數據用良好的可視化界面展現給用戶，為用戶提供服務。

圖3T系統框架圖

一、用戶層

用戶層是與用戶直接接觸的一層，為用戶提供各種界面化的服務，包括各功

能菜單入口，用戶通過點擊界面上的菜單按鈕進行日常業務工作。用戶層類似于

MVC模式中的視圖層。該層主要用于向用戶展現數據，可解釋為UI （User

Interface）層。在開發系統時，需要將系統易操作性、易掌握性、高效性及良好的用戶體驗放在第一位。用戶層與應用層有緊密的聯系，用戶層可以將用戶在界面上輸入的數據信息傳遞給應用層，應用層將數據計算的結果推送給用戶層，用戶層將數據渲染到前端用戶界面展示出來。用戶層和應用層的聯系如下圖3-2所

Zjs o

圖3-2用戶層與應用支撐層關系圖

二、應用層

應用層在MVC設計模式中類似于Controller （邏輯控制層），提供控制業務功能流轉的功能。應用層是連接用戶層和數據層的核心層，應用層下面的應用支撐層是為應用層提供服務的。在設計應用層的時候，需要考慮多用戶同時請求時, 系統的響應速度。多用戶并發請求是影響系統響應速度的一個關鍵因素，目前有很多技術來解決響應速度的問題，比如負載均衡服務器Nginx、分布式服務器等。目前系統使用對象為研究所內職工，人數大概在幾百人，并發訪問量可以通過 BPM平臺做好控制，提高系統響應速度。

三、應用支撐層

應用支撐層為應用層提供服務，如此分層的目的是使應用層的代碼更加專注于業務實現，業務邏輯代碼更加純粹。BPM平臺在實現業務功能時，主要使用三類模型完成，包括流程模型、表單模型、數據模型，這三類模型均屬于應用支撐層。其中，三個模型間的關系設計借鑒了 MVC模式的思想，流程模型負責建設流程的節點及流程的跳轉；表單模型是數據的展現，表單模型是依托在流程上的；數據模型相當于面向對象的數據庫編程模型，類似于ORM框架。

四、數據庫層

數據庫層負責數據的存儲。數據庫的存儲空間一般是服務器上的硬盤空間， 10操作是比較耗時的一個問題，也是影響系統性能的一個瓶頸。數據一致性問題可以使用數據庫中的事務和鎖機制來解決。系統開發采用SQLServer數據庫, 可以借助SQL Server的鎖定機制來實現多個用戶同時訪問同一數據。數據庫層就類似于MVC模式中的Model層，為應用層與數據庫的數據交互提供了服務。

3.1.2.2系統模塊劃分

根據對研究所設備信息管理系統的需求分析與建設目標，系統功能模塊概要設計如圖3-3所示。本系統是本人與實驗室另一同學共同完成的，本人主要負責部分業務模塊，模塊設計內容將圍繞負責模塊展開介紹。

圖3-3設備信息管理系統功能模塊設計圖

3.1.3核心模塊詳細設計

本小節是對功能模塊做詳細設計，畫出模塊的功能流程圖，并介紹流程中每一節點的作用，流程實際執行步驟。基于概要設計，對每個功能模塊詳細設計，旨在為實現系統功能做好準備工作。

3.1.3.1供應商管理

1.普通用戶-供應商新增

普通用戶在錄入供應商信息時，由于普通用戶權限較小，所以只能通過供應商新增流程提出新增申請，然后需要通過各級領導的審批，只有審批全部通過后，供應商新增成功，該功能采用流程模型設計并實現。普通用戶錄入供應商過程如圖3-4所示。

1填寫供應商基

本信息

蠡淋溺軸-Y縫議 4 ! @

圖3-4供應商新增模塊詳細設計流程圖

流程描述如下：

（1）普通用戶登錄系統填寫供應商新增申請單，填寫供應商詳細信息，提交信息至節點二由部門領導審批。

（2）部門領導登錄系統審查上一節點提交過來的供應商信息。同意則提交至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

（3）設備儀器主管登錄系統審批節點二提交過來的審核信息及供應商信息, 選擇審核結果。選擇同意則跳轉至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

2.普通用戶-供應商查詢

普通用戶可查詢所有供應商信息，在一些功能模塊中，普通用戶在填寫申請表時選擇相應的供應商信息。普通用戶可查看供應商姓名、電話、聯系人等主要信息，使用Report報表來展現。

3•設備儀器主管-供應商維護

不同于普通用戶，設備儀器主管的權限比普通用戶的權限大，可以對供應商基本信息進行維護。維護內容主要包括增刪改查。做好供應商基礎信息的管理工作有利于設備的購置及質量把控。實現該類功能可以使用用戶視圖，用戶視圖模型提供了對數據庫數據增刪改查的功能。

3.1.3.2采購管理

研究所設備儀器管理辦法中指出采購管理需要滿足設備的申請審批的需求，申請過程必須嚴格記錄各級領導的審批意見，且對特殊設備（單價＞=20萬）特殊審批，添加撰寫論證報告子流程。論證子報告流程中關聯論證報告表單，該表單主要用于填報設備單價不小于20萬的設備采購申請的說明，實現設備采購管控。在設計采購審批流程時考慮如下條件：

1•一個申請表中包含的設備信息可能既有不小于20萬的設備，又有小于20 萬的設備，對以上兩種情況需要有不同的處理方式；

2•設備類型不止一種，那么在設備主管審批的節點，需要考慮怎么將子表內容拆分，分別提交給設備類型對應的設備主管完成審批，當該節點的所有主管審批完成后才能繼續進行到下一節點；否則，流程停留在當前節點。設備主管包含辦公室主管、質量處主管等，旨在通過權限劃分，提高各類設備的管理效率。

3.涉密設備需要保密處審批，非涉密設備不需要保密處審批，需要根據實際情況決定流程是否需要走保密審批的節點。保密處用于審核涉密設備的相關審批，實現涉密設備的安全性管控；

4•大于20萬的設備如果沒有填寫論證報告，提交表單時不能通過表單檢驗，需要提示用戶補充完善論證報告。

購置審批流程圖如圖3-5所示。

流程描述如下：

1•普通用戶登陸系統填寫購置申請單，如果擬購置物品的單價＞=20萬元，則不小于20萬的設備需要填寫論證報告，填寫完論證報告后提交，提交時校驗需要填寫論證報告的行記錄是否填寫了論證報告，如果沒有填寫校驗失敗，提示用戶必須填寫論證報告，校驗通過則跳轉至節點二；如果擬購置物品都小于 20萬，則跳轉至節點三。

2.部門領導（副職或總工）登陸系統在代辦任務中審核設備儀器論證報告，選擇審核結果。選擇同意則跳轉至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

3.部門領導（一把手）登陸系統在代辦任務中審批購置申請單。注意部門領導在審批通過并提交時，系統需要判斷表單中的設備是否有涉密設備，若有涉密設備需要跳至第四節點由保密處審批，否則跳轉至第五節點由設備儀器主管人員審批；否則需填寫審批意見并跳轉至第一節點重新提出申請。。

4.保密處人員登陸系統在代辦任務中審批購置申請單，審批通過則跳轉至下一節點繼續審批；否則需填寫審批意見并跳轉至第一節點重新提出申請。

5•設備儀器主管人員登錄系統在代辦任務中審批購置申請單，選擇同意或不同意，選擇同意后，在提交時系統需要判斷表單中的設備是否需要主管所領導審批，如果需要，則跳轉至第六節點由主管所領導審批，否則跳轉至節點七由安全技術處主管查看設備購置信息；選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

6.主管所人員登陸系統在代辦任務中審批購置申請單，選擇同意或不同意，選擇同意則跳轉至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

7•安全技術處主管登陸系統在代辦任務中審批購置申請單，查看申請表單信息，獲知各部門購置的設備信息。安全技術處主管不對購置申請做審批工作, 只查看表單信息。

3.1.3.3驗收入賬管理

驗收入賬管理區別于直接入賬管理，在需求中已經提到過，驗收入賬管理功能是針對非信息化中心部門。直接入賬管理功能是針對信息化中心部門；驗收入賬管理功能比直接入賬管理功能多了到貨驗收的部分。將驗收流程與入賬流程合并為驗入賬流程的目的是方便數據的傳輸。

驗收入賬過程如圖3-6所示，描述如下：

1 •使用人員在設備到貨后登錄系統填寫到貨驗收單（如無需驗可直接發起入賬流程），啟動流程，如果設備單價大于5萬或屬于特種設備，跳轉到節點二由情報驗收員審批；如果設備屬于計量器具，跳轉到節點三由質量保障處審批；否則判斷設備是否涉密，如果涉密則跳轉到節點四，由保密處人員審批，如果設備不涉密，則跳轉至節點五，由設備儀器主管人員審批。在提交表單時, 需要校驗供應商是否存在于供應商表中，若不存在，需要啟動供應商錄入流程, 將新的供應商信息更新至數據庫表中，該模塊涉及到子流程嵌套的問題。

2.情報驗收員登錄系統進行流程審批,選擇同意或不同意，選擇同意后，在提交時系統需要判斷表單中的設備是否涉密，是否為計量器具，如果涉密且不為計量器具，則跳轉至第四節點由保密處人員審批；如果不涉密且不為計量器具則跳轉至節點五，由設備儀器主管審批設備購置信息；否則跳轉至節點三由質量保障處審批。選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

3.質量驗收員登錄系統進行流程審批，選擇同意或不同意，選擇同意后，在提交時系統需要判斷表單中的設備是否涉密，若涉密則跳轉至節點四，由保密處人員審批，否則跳轉至幾點五由設備儀器主管審批。選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

4.保密處管理人員登錄系統進行流程審批選擇同意則跳轉至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

5•設備儀器主管人員登錄系統進行流程審批，在審批時，需要注意如果資產類型為特種設備時點擊提交需彈出選擇框讓設備儀器主管選擇特種設備子類型。如果資產類型為信息化設備時點擊提交需彈出選擇框讓設備儀器主管選擇信息化設備類型。選擇同意則跳轉至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

6•以上五步為設備驗收流程，下面為設備入賬流程。驗收流程發起人登錄系統查看待辦工作，填寫入賬單，設備到貨驗收完成后系統自動啟動入賬流程。按照設備類型需要設計五個表單信息,每個表單信息對應如下五大類設備類型:

(1)通用設備、專用測試設備、信息化設備、電梯、空調

(2)起重機械、場內專用機動車入賬(與通用設備一致)

(3)安全附件入賬

(4)計量器具入賬

(5)車輛入賬

7.設備儀器主管人員登錄系統進行流程審批，并選擇設備類號，自動生成固定資產編號，固定資產編號是標識設備的唯一編號，不能重復；選擇臺賬產權，包括航動、航化、時翼等；選擇設備屬性，包括A類及B類。選擇同意則跳轉至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新

提出申請。

&安全技術處主管人員登錄系統進行流程審批，審批菜單同其他審批節點。流程結束后入賬單自動推送到財務處。

入賬數量決定生成的記錄數（單個設備需要生成唯一的編號），固定資產編號通過選擇設備或儀器類別來生成（編號規則見基礎數據，類號+0001（流水號））。在設備驗收流程中，設備隨機資料能夠生成歸檔清單，供情報驗收員核對。

圖3-6到貨驗收入賬審批詳細設計流程圖

3.1.3.4直接入賬管理

直接入賬流程可以看作是驗收入賬流程的后三個節點組成的子流程。直接入賬過程如圖3-7所示，在第二個節點時需要注意，若設備類型為特種設備時點擊提交需彈出選擇框讓設備儀器主管選擇特種設備子類型。如果設備類型為信息化設備時點擊提交需彈出選擇框讓設備儀器主管選擇信息化設備子類型。

圖3-7直接入賬審批詳細設計流程圖

3.1.3.5其他資產入賬管理

其他資產入賬管理類似于直接入賬流程，不同之處是其他資產入賬流程需要部門領導進行審批，流程圖如圖3-8所示。流程描述如下：

1.普通用戶填寫其他資產入賬單，并提交入賬單給部門領導審批。

2•部門領導登陸系統在代辦任務中審核入賬申請單信息，選擇審核結果。選擇同意則跳轉至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

3.設備儀器主管登陸系統在代辦任務中審批購置申請單，選擇同意或不同意，選擇同意后，則跳轉至第四節點由安全技術處主管審批；選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

4•安全技術處主管登陸系統在代辦任務中審批購置申請單，選擇同意或不同意，選擇同意則跳轉至下一節點繼續審批，選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

3.1.3.6領用管理

領用管理給用戶提供了領用本部門已入賬且狀態為可用設備的服務，這里涉及了資源訪問控制，設備領用人只能領用本部門的設備。流程圖如圖3-9所示，流程描述如下：

1•領用設備的人員登錄系統發起領用流程，填寫領用申請單并提交給部門領導審批。

2.使用部門領導登錄系統進行流程審批，選擇同意或不同意，選擇同意后，則跳轉至第三節點由設備儀器主管審批；選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

3•設備儀器主管進行設備實發信息的錄入，進行實物發放，注意發放的實物可能與申請的設備不同，所以需要設計下一個節點進行確認。選擇同意或不同意, 選擇同意后，則跳轉至第四節點由使用人確認；選擇不同意則填寫審批意見并跳轉至第一節點重新提出申請。

4•使用人登錄系統進行確認，流程結束。

結束

圖3-9領用管理詳細設計流程圖

3.1.3.7特種設備管理、車輛管理

特種設備管理模塊負責特種設備的檢定管理，能夠根據上次設備檢查的時間和有效期，自動生成下次檢驗的時間。設備檢定管理對于設備管理很重要，周期化的檢定方式可以有效發現故障設備，提高設備管理效率，盡早發現設備缺陷。不同的角色對特種設備的管理也不同，安全技術處主管具有查看、導入導出、編輯、查詢、打印標簽等權限；部門系統管理員具有查看、查詢本部門臺賬、編輯上次檢定時間、有效期的權限；普通用戶具有查看、查詢責任人為本人的臺賬，編輯上次檢定時間、有效期的權限。車輛管理與特種設備管理類似，不過車輛定期檢查是為了保證行駛安全，交通運輸工具必須要定期檢查，提前發現可能損壞的設備，減少經濟損失，保障人員安全。車輛管理模塊類似于特種設備管理模塊, 主要對車輛的檢定周期進行管理，不同角色也有不同的管理權限。部門系統管理員具有查看、查詢本部門臺賬，編輯上次檢定時間、有效期的權限；普通用戶具有查看、查詢責任人為本人的臺賬，編輯上次檢定時間、有效期的權限。

3.1.3.8預報管理

設備儀器主管人員需在預報管理模塊中設置各類設備的提前預報量，如壓力容器為一個月，系統自動判斷各類型設備的提前預報量，超過預報量未進行檢定或檢驗的設備系統自動向安全技術處主管級部門管理員以設定方式發送預警。預警時間、預警規則和默認設置的單位都是天，如果填寫提前預警天數為40天，

預警周期為5天，默認持續預警天數為3天，則代表提前40天開始預警，每隔 5天提醒一次，最后3均需提醒。預警時間能夠設置每天的提醒時間，可設置多個時間。預報管理主要提供設備類型與對應的預警時間數據增刪改查的功能，還提供預警信息反饋的方式。可以使用消息提醒和郵件提醒兩種預警方式給用戶發送告警信息。

3.1.3.9基礎數據管理

基礎數據管理包括資產類型、試驗臺、檢定周期、使用狀態、計量器具及分類碼、設備主管與設備類型對照表。

一、資產類型

隨著航天研究所業務的不斷擴展，研究所設備而種類越來越繁瑣，并且資產類型的數據幾乎貫穿于設備生命周期內的管理業務中，資產類型管理模塊是很重要的。該基礎數據管理模塊為用戶提供了管理資產類型的功能，用戶可以根據實際需求修改資產類型。資產類型分類如圖3-10所示。

圖3-10資產類型三級分類圖

二、試驗臺、檢定周期、使用狀態

試驗臺是為設備采購服務的，設備采購過程需要選擇設備是否為試驗臺，試驗臺管理員具有錄入、維護信息等權限；檢定周期是為特種設備和車輛管理服務的，檢定周期使得維護更加方便，用戶可以通過檢定周期管理自定義檢定時間。設備儀器主管具有錄入、編輯、保存、刪除等權限；使用狀態是為臺賬管理服務的，臺賬中需要對設備狀態進行管理，設備狀態主要包括可用、在用、閑置封存、報廢及設備維修中。在一些業務流程走完后，需要更新臺賬中的設備狀態。例如, 入賬流程結束后需要將設備狀態更新為可用；設備領用流程結束后需要將設備狀態更新為在用。

三、計量器具及分類碼

可根據下表3-1建立計量學學科、可測量的量、計量器具、工作計量器具的基礎庫，為入賬時生成分類代碼提供基礎數據選項。質量處主管具有錄入、編輯、保存、刪除等權限。

表3T計量器具分類代碼庫表

計量器具分類代碼庫

計量學學科可測量的量計量器具工作計量器具代碼

幾何量線紋計量器具基線尺基線尺 _ 01 25 07 00

光柵尺光柵尺 01 25 08 00

線紋尺金屬線紋尺 01 25 11 01

玻璃線紋尺 01 25 11 02

卷尺鋼卷尺 01 25 14 01

皮卷尺 01 25 14 02

直尺鋼直尺 01 25 17 01

比例尺比例尺 01 25 24 00

容柵尺容柵尺 01 25 28 00

水準尺水準尺 01 25 31 00

標尺標尺 01 25 36 00

四、設備主管與設備類型對照信息維護

在設備采購的設備儀器主管審批節點中，每種設備儀器主管只能看到其負責的設備類型的設備信息，所以通過維護一個信息對照表，將允許顯示的子表信息顯示在表單中。設備采購流程中涉及到子表拆分技術及并簽技術，在論述設備采購流程的實現部分時將會詳細描述。設備儀器主管具有錄入、編輯、保存、刪除等權限。設備主管與設備類型的對照信息如下表3-2所示。

表3-2設備主管與設備類型對照表

設備主管與設備類型關系對照表

設備主管設備類型

信息化中心主管信息化設備

辦公室主管車輛

行政處主管空調、電梯

質量處主管計量器具

特種設備主管特種設備

安全技術處主管車輛、通用設備、專用測試設備、特種設備、通用儀器、信息化設備、計量器具、車輛、空調、電梯、辦公營具

3.1.3.10組織權限管理

組織權限模塊主要包括角色、用戶、權限及部門管理等。角色的詳細描述如表3-3所示系統的大多數功能是基于流程驅動的，流程是由多個節點串聯起來完成的，每個節點對應不同角色的人員來審批流程事件，角色管理方便指定節點辦理角色。用戶管理主要是對系統賬戶信息進行管理，包括用戶凍結解凍、角色指派、修改密碼等功能，其中用戶被賦予某種角色后就擁有角色對應的訪問權限。

表3-3系統角色詳細描述表

角色名稱系統工作

普通用戶發起流程、提交材料、檢索、發布權限內的設備儀器信息;

部門管理員發起工作流程、提交相關材料、查詢、檢索、發布權限內: 的設備儀器信息

設備儀器管理員負責錄入主管流程中的相關信息，提交相關材料，審批流; 程并監控流程執行情況

信息化設備管理員負責錄入主管流程中的相關信息，提交相關材料，審批流程并監控流程執行情況 I

特種設備管理員負責錄入主管流程中的相關信息，提交相關材料，審批流' 程并監控流程執行情況

計量器具管理員負責錄入主管流程中的相關信息，提交相關材料，審批流程并監控流程執行情況，參與計量器具的驗收 I

行政處管理員負責錄入主管流程中的相關信息，提交相關材料，審批并; 監控流程執行情況 I

車輛管理員負責錄入主管流程中的相關信息，提交相關材料，審批流程并監控流程執行情況

（續上表）

角色名稱系統工作

部門領導 ;負責審批本部門的流程并監控流程執行情況，查看本部門的設備信息

檔案驗收員參與單價大于5萬或特種設備的驗收,審核歸檔文件清單

科研生產業務主管；負責設備變動相關流程的審批

入賬員接收相關流程并錄入相關信息

所領導；負責相關流程的審批

系統管理員；建立系統的組織結構并實時更新系統用戶

安全保密管理員 |建立角色并為角色分配相應人員，審計日志

審計管理員按時對系統管理員和保密管理員的操作日志審計

3.2系統數據庫設計

根據業務需求，本系統的建設使用關系型數據庫。在設計關系型數據庫時需要注意確保完整性、降低冗余性、提高穩定性a。】。數據庫設計屬于項目開發前期中的重要工作，優秀的數據庫設計會提高項目開發效率，提高系統健壯性。結合BPM開發架構中使用@公式將用戶層的數據與數據庫表中的數據映射起來的特點，我們在設計數據庫時需要考慮在實際的業務流程中，數據庫該如何設計。

3.2.1系統數據表關系圖

系統業務功能模塊較多，數據庫表和表關系繁瑣，如圖3-11所示，展示了組織權限中表之間的關系，以及流程表與用戶表等之間的關系。

圖3T1部分數據表關系圖

3.2.2系統數據表詳細設計

由于業務模塊較多，涉及到的數據表也比較多，如果詳細介紹每個表的字段會使得篇幅較長，所以這里主要介紹各個模塊相關的表信息。系統數據庫中的表信息如表3-4所示。

表3-4數據庫表

模塊表名描述說明

組織 ORGUSER 賬戶數據表賬戶管理

模塊 ORGROLE 角色數據表角色管理

管理 ORGDEPARTMEN

T 部門數據表部門管理

SYSSECURITYG

ROUP 權限組權限管理

SYSROLESECU

RITY 角色與權限組隸屬關系角色權限管理

前期

管理 BO_SBGL_COM

MON 公共數據表公共數據表

模塊 BO_SBGL_GYSZ

B 供應商主表供應商新增流程

（續上表）

模

塊表名描述說明

1 BOSBGLGYS 供應商表

BOSBGLSBCG 設備采購主表表設備采購流程

BOSBGLSBCG

_S 設備采購信息表

BO_SBGL_SBCG

LZBG 設備采購論證報告信息表

BOSBGLSBYS 設備到貨驗收信息表設備到貨驗收流程

BO_SBGL_SBYS_

SJZL 設備驗收隨機資料數據表

BO_SBGL_SBRZ_

MAIN 設備入賬主表設備入賬流程

BOSBGLSBRZ 設備入賬信息表

BO_SBGL_QTZC

RZMAIN 其他資產入賬主表其他資產入賬流程

BOSBGLQTZC

RZ 其他資產入賬信息表

BOSBGLLYXX 設備領用主表設備領用流程

BOSBGLLYXX

_S 設備領用信息表

臺賬 BOSBGLZTZ 總臺賬總臺賬、特種設備、車輛

基 BOSBGLZCLX 資產類型數據表資產類型 1

BOSBGLSBLX 設備類型

數

據 BO_SBGL_TZSB

LX 設備子類型

管 BOSBGLSYT 試驗臺信息數據表試驗臺管理

理 BOSBGLJDZQ 檢定周期信息數據表檢定周期管理

模 BO_SBGL_SYZT 使用狀態信息數據表使用狀態管理

塊 BOSBGLJLQJ 計量儀器分類代碼計量器具管理：

BO_SBGL_JLQJ_

KCL 可測量的量數據表

（續上表）

模

塊表名描述說明

BO_SBGL_JLQJ_

QJ 計量儀器數據表

BO_SBGL_JLQJ_J

LQJ 工作計量儀器數據表

BO_SBGL_SBZG

LX 主管與設備類型對照表設備主管與設備類型關系

預報管理 BOSBGLYBGL 預報管理主表預報管理

3.3設備信息系統的實現

本小節主要介紹BPM開發框架實現業務流程開發的詳細過程及設備信息管理系統主要模塊的實現。設備信息管理系統是在BPM開發框架中實現的，在第二章節中也詳細論述了 BPM框架的相關技術要點，BPM框架擁有自己的Local API,也給開發者提供了豐富的功能擴展接口，雖然BPM框架封裝了一些可直接調用的組件，但是在實際的業務流程開發過程中，需要開發人員靈活擴展框架功能，通過設計巧妙的實現方式，達到高效快速開發系統的目的。設備信息管理系統中的核心模塊主要是由流程驅動的，流程中涉及很多小細節，包括流程跳轉控制，流程表單內容的控制，節點辦理人的控制，節點事件的觸發，流程事件的觸發，子流程的開啟控制，流程并簽與會簽等。在業務流程開發之前需要對業務功能作詳細的設計，文章在第三章節中的系統設計部分也重點論述了該部分內容。

3.3.1開發環境介紹

開發環境在Windows 7平臺上搭建，項目部署在Windows Server 2003版本的服務器上。開發環境主要包括BPM平臺、BPM Developer集成開發工具＞Eclipse 工具、Notepad++編輯器、SQLSERVER 數據庫、JBoss 服務器等。Windows Server 2003服務器主要用于應用系統服務器及Windows Active Directory （AD目錄）服務器；用戶使用Win7系統的IE8瀏覽器訪問系統；BPM平臺主要用于流程模型開發，其提供的流程模型接口方便了流程的建設；BPM Developer是對Eclipse 開發工具的封裝，提供Local API及封裝好的一些工具接口。環境搭建主要包括以下內容：

(1)在Windows Server 2003服務器上搭建AD域；

(2)將終端機器加入域中；

(3)在Windows Server 2003服務器上安裝并配置SQL Server數據庫；

(4)在Windows Server 2003服務器上安裝并配置BPM運行環境；

(5)在Windows 7上安裝并配置Developer開發工具、數據庫管理可視化工具和Eclipse集成開發平臺。

(6)測試環境，使用開發工具寫個測試小項目，測試數據庫連接，應用服務器等是否正常。

3.3.2模型實現技術

系統實現章節主要介紹各個功能模塊的實現，基于流程和基于報表實現的功能模塊，其實現方式大同小異，所以本小節將共有實現方式提取出來，詳細介紹一般流程和報表的實現方式。

流程模型實現是基于數據模型和表單模型。數據模型對應庫中的表對象，表單模型是由JS、HTML、CSS、EXTJS、AJAX技術實現，同時包括使用@公式將數據模型中的數據展現出來，流程模型通過在節點上綁定表單，基于數據驅動，完成流程的構建。下面詳細論述三種模型核心實現方法。

一、數據模型實現類

數據模型，其實例即為文中提到的BO數據表。每個流程實例都需要與流程中所用到的BO數據表和數據聯系，所以對BO數據表的處理過程進行了封裝。 AWS開發框架中，BO數據表處理類為BOInstanceAPI,類圖如圖3-12所示。

-boinstanc^PkBCMstan^APL

-r createBoData(paranis):int

于 updatsBOData^ramsJint

圖3T2數據模型處理類圖

BOInstanceAPI類包括一個私有靜態屬性boInstanceAPR 一個公有靜態方法 getlnstanceO和多個公有非靜態方法。當需要調用該類的非靜態方法時，先通過

調用靜態方法getlnstance()獲取BOInsatnceAPI類的實例，然后使用實例對象調用各個公有方法。調用方式如下：

BOInstance API. getlnstance().［公有方法名］;

BOInstanceAPI公有方法主要提供對數據庫數據增刪改查的功能，下面解釋主要方法。

(1)增加數據的方法：int createBOData(String,Hashtable,int, String)。該方法是給流程實例中的某一數據表新增數據記錄。

(2)查詢數據的方法：getBOData(String,int)、getBODatas(String,int)、 getBODatasBySQL(String,String) o

該方法提供數據查找功能。getBODatas(String,int)是查詢多行記錄，指明查詢的是哪~工作流實例的哪些記錄；getBOData(String,int)是查詢一條記錄，類似于getBODatas(String,int)方法，適用于流程實例中的數據查詢； getBODatasBySQL(String,String)是通過where條件語句查詢多條記錄，即可根據 Where子句查詢需要的數據。

(3)更新數據的方法：updateBOData(String,Hashtable,int)□

該方法是更新數據庫中的表數據。

(4)刪除數據的方法：removeBOData(String,int)<>

該方法是刪除數據庫中的表數據。

二、流程模型實現類

流程模型主要用于創建業務流程實例，基于流程實現的功能模塊都有自身的流程模型，用戶在使用這些功能時，實際上是對流程實例進行操作。流程實例的創建主要包括節點的建立、節點間聯系的建立、流程啟動等方法，為了方便對流程實例對象和流程節點對象的管理，AWS開發框架分別封裝流程實體類和流程節點實體類，兩個類包含的主要方法和說明如下圖3-13和圖3-14所示。

圖3-13流程模型處理類圖

Workflowinstance API 類包括 _個私有靜態屬性 workflowinstance API > _個公有靜態方法getlnstanceO和多個公有非靜態方法。當需要調用該類的非靜態方 50

法時，先通過調用靜態方法getlnstance()獲取workflowInsatnceAPI類的實例，然后使用實例對象調用各個公有方法。調用方式如下：

Workflo wlnstanceAPI. getlnstance().[公有方法名];

WorkflowInstanceAPI公有方法主要提供對流程實例增刪或者流程變量賦值的功能，下面解釋主要方法。

(1)int createProcessInstance(String,String,String) 該方法提供新建工作流實例并開啟實例的功能。

(2)int assignWriable(int,String,String)

該方法用于給流程變量賦值。

(3)HashtablegetVariables(String,int,int)

該方法提供了獲得某一實例的所有變量及其值。

(4)String getVariable(String,int,int,String)

該方法用于獲取流程實例中指定變量的值，類似于getVariables()方法。

(5)voidcloseProcessInstance(String,int,int)

該方法用于關閉一個工作流實例，并觸發流程結束時需要執行的事件。

(6)voidremoveProcessInstance(int)

該方法用于刪除一個實例。

(7)int[] createSubProcessInstance(String,int) 該方法用于為實例創建一個或多個子流程實例。

•f createPiwessTasIdnstanceiparamsJiini-n

手remave^foc^ssTs^HstanceCparam^^oid

4- 9etHexfete0Ho(p^ams)^nt

4- gHAdivityPartidpanMpsramsJiStrir^

圖3-14流程節點處理類圖

WorkflowTasklnstanceAPI 類包括一個私有靜態屬性 workflowTasklnstanceAPL 一個公有靜態方法getlnstance。和多個公有非靜態方法。當需要調用該類的非靜態方法時，先通過調用靜態方法getlnstance()獲取 workflowTasklnsatnceAPI類的實例，然后使用實例對象調用各個公有方法。調用方式如下：

WorkflowTaskInstanceAPI. getlnstance().[公有方法名];

WorkflowInstanceAPI公有方法主要提供對流程實例增刪或者流程變量賦值的功能，下面解釋主要方法。

(1)int[] createProcessTaskInstance(String,int,int,String,String)

該方法用于給實例創建新的節點，新的節點相當于給節點參與者新增了一個待辦任務。

(2)int[] appendOpinionHistory(String,int,int,String,String)

該方法用于給當前流程節點創建一個加簽的任務，即暫停執行該節點任務，給當前任務增加辦理人，當增加成功后再繼續執行該任務。

(3)booleancloseProcessTaskInstance(String,int,int)

該方法用于關閉當前執行的實例。

(4)void removeProcessTasklnstance(int)

該方法用于刪除一個待辦任務。

(5)String getAuditMenus(int)

該方法用于獲取某一任務實例的審核菜單。

(6)booleanisClose(int)

該方法用于判斷任務實例是否己經結束。

(7)String getActivityParticipants(String,int,int,int)

該方法用于獲取當前任務實例節點的辦理者。

(8)String getNextParticipant(String,int,int)

該方法用于獲取下一節點的參與者的列表。

三、報表模型實現

報表模型實現UML類圖如圖3-15所示，在類圖結構中，可以看到為了提高每類報表的擴展性，將每類報表通過接口的形式定義，然后通過抽象類 FormatReportAbs來綜合各類報表的特點。在創建報表實例時，首先創建一個繼承FormatReportAbs非抽象類，實現父類中的三個抽象函數，然后就可以構造三種類型的報表內容了。

Forinat&ccelRepQrtlnterface FormatHtmlReportlnterface FormatSqlRepcrtlnterface

+ fonnatExce^arams^HSSFWoricbook + formatSql^)3ram§):Sthng

T T

abstract

+ farmatExcei(param5)2HSSFWorkbi3ok

+ f«rmat(params):Table

+ f£tn*natSql(paraim$):StFinQ

+ formatExcei^iaramsJiHSSFWcrldJspk

* format伽rams) T^sle

+ formatSql^>arffln5)iStmig

-getColumnIndexCpatams)^t

-getfieldCo1Irxiex^3rams):int

圖3-15報表類圖

在非抽象類ReportAbsExample中包含了三個公有方法和兩個私有方法。三個公有方法即時實現抽象父類中的構造三種報表格式的方法。可通過 formatExcel(params)方法將數據以Excel表格的形式輸出；可通過fbnnat(pararns) 方法將數據以網頁表格的形式輸出；可通過fbrmatSql(params)方法將數據以SQL 報表的形式輸出。

3.3.3供應商管理

普通用戶查看供應商信息通過用戶報表實現，普通用戶新增供應商信息通過流程實現，設備儀器主管維護供應商信息通過用戶視圖實現。三個子功能共用供應商數據主表(BO_SBGL_GYSZB)和供應商數據子表(BO_SBGL_GYS),下面分別描述三個子功能的實現過程。

一、普通用戶查詢供應商信息

該功能使用報表模型實現，編寫SQL語句查詢數據表(BO_SBGL_GYS)。在查詢供應商信息時，每頁顯示20條數據，條件區每行三列，通過菜單入口打開報表時自動執行結果，對于查詢結果提供查看詳情的鏈接、顯示的字段包括供應商名稱、主營業務等信息。查詢過濾條件包括供應商名稱、聯絡人等。過濾條件之間屬于“相與”的關系，查詢結果排序通過供應商名稱自然順序升序排序。主要的SQL語句如下代碼所示：

SELECT

BO SBGL GYS.GYSMC,

BO_SBGL_GYS.GYSZYYW,

BO_SBGL_GYS.GYSLLR, BO_SBGL_GYS.GYSDH, BO_SBGL_GYS.GYSCZ AS, BO_SBGL_GYS.GYSBGDZ, BO_SBGL_GYS.GYSKHH5 BO_SBGL_GYS.GYSZH, BO_SBGL_GYS.GYSYB, BO_SBGL_GYS.BINDID, BO_SBGL_GYS.ID

FROM BO_SBGL_GYS

WHERE 1=1

ORDER BY BO_SBGL_GYS.GYSMC

ASC

二、普通用戶新增供應商

功能模塊的時序圖如圖3-16所示，時序圖中只展現了流程的正向邏輯，若有審核節點選擇了“不同意”的審核菜單，流程均會跳轉到第一節點由申請人重新提出申請。

設備儀器主管權限比普通用戶權限大，負責維護供應商信息，包括增刪該查操作。該功能模塊主要使用表單模型和用戶視圖來實現，用戶視圖是通過 BOInstanceAPI類的增刪改查的方法實現與數據庫的數據交互的。用戶視圖屬于一種特殊的流程，只不過其改進了流程模型的原理，只保留一個節點，通過使用單例模式確保數據一致性。在部署功能模塊時，查看供應商報表和供應商新增流程的權限會授權給普通用戶，在普通用戶登錄到系統時會看到此這兩個功能的菜單入口；供應商維護管理權限會授權給設備儀器主管，設備儀器主管在登錄到系統時就會看到供應商維護管理的菜單入口。

3.3.4設備采購申請流程

設備采購需要經過審批流程，一般由普通用戶發起。設備采購功能的實現需要兩個數據表及設備采購申請單。BO數據表分別是設備釆購主表 (BO_SBGL_SBCG)和設備采購子表(BO_SBGL_SBCG_S),設備采購主表字段和設備采購子表字段己在數據庫設計小節中介紹。該模塊時序圖如圖3-17所示。設備采購申請流程中的設備主管審核節點中，采用了數據信息拆分的技術，即表單中的設備數據需由相應的設備主管審批，在流程跳轉到設備主管節點時，通過編寫子表過濾事件，控制數據展現。子表過濾事件的類為 SheetFilterRTClassA,包括 acceptRowData()、rowDataFilter()等方法，提供了按條件顯示子表數據的功能。設備采購審批過程中嵌套了論證報告子流程。當子表中的設備單價超過20萬時，當前行會觸發一個新的論證報告流程實例。點擊“提交” 按鈕時，節點事件會觸發后臺程序檢驗論證報告內容是否為空，校驗通過才可提交。

設備釆購申請流程共包括七個節點，除第一個節點外，每個節點都有兩個審核菜單，即“同意”和“不同意”。該功能模塊的時序圖如圖所示。在時序圖中，只突出了每個節點的“同意”審核菜單。若審批時選擇了“不同意啲審核菜單，那么流程會跳轉到第一個節點，由申請人重新申請。

~~I I普通用戶I I部門分管領導I部門領導I保密處領導I設備主管I 住管卿歸安全技術雌管

1 I 1 1 - 1 1 1 1 L 1 * 1 1 1 1 I 1

圖3-17設備采購申請模塊時序圖

論證報告實際上也是一個流程。該流程的實現需要一個BO數據表 (BO_SBGL_SBCG_LZBG)和一個設備購置論證表單。論證報告子流程是由設備采購申請子表中的行數據觸發的，若該行數據中的單價大于20萬，則在子表中的“論證報告”顯示“查看”按鈕；否則，則不會出現“查看”按鈕。用戶點擊“查看' 按鈕會觸發后臺程序根據論證報告流程模型創建一個流程實例，論證報告子流程實例就創建完成了。每個子流程實例數據與采購申請子表中的一行相對應，即每一份論證報告對應一個單價大于20萬的設備的釆購說明。另外，設備采購申請流程還提供了表單打印功能，在流程結束后，用戶可根據需要打印設備采購申請表單。

3.3.5設備驗收入賬流程

設備驗收和入賬是兩個子功能，但由于設備驗收和入賬數據需要保持一致，即后者的數據來源于前者，所以將兩個子功能結合到一起來實現。該功能模塊是由流程模型來實現的。流程模型的實現需要四個BO數據表和兩個申請表單。流程實例前五個節點綁定的是設備到貨驗收申請表單，該表單包括設備到貨驗收信息表(BO_SBGL_SBYS)、設備驗收隨機資料數據表(BO_SBGL_SBYS_SJZL) 數據表；流程實例的后三個節點綁定的是設備驗收入賬表單，該表單包括設備入賬主表(BO_SBGL_SBRZ_MAIN)、設備入賬信息表(BO_SBGL_SBRZ)數據表。

設備驗收入賬流程第一個節點后有可能需要走供應商管理子流程，在業務需求中提到了若在填寫設備驗收申請表單時，填寫的供應商信息沒有存在于供應商名冊中，需要觸發供應商新增申請流程,將新的供應商名稱添加至供應商名冊后，再繼續執行流程。所以，在建立流程節點的系統規則時，會判斷供應商信息是否已經存在，沒有存在就會觸發啟動子流程。在設備驗收申請表中，需要驗收的設備是從已采購的設備中挑選的，且設備驗收人只能選擇自己采購的且未被驗收的設備，為了及時更改設備狀態，在第一個節點辦理后，需要將設備狀態改為正在驗收中。更改設備狀態用到了節點事件觸發器。設備名稱的選擇使用到了數據字典類型的UI組件，該組件可以利用sql語句和@公式從數據庫中獲取數據。該功能模塊的時序圖如圖3-18所示，與采購模塊類似，這里只介紹了流程正向執行的順序，若審核時選擇“不同意”時，則流程跳轉至第一個節點，由申請人重新

圖3-18設備驗收入賬模塊時序圖

設備驗收入賬流程實例的后三個節點屬于真正的入賬流程，入賬申請表單中的信息是從驗收表單中復制拓展得到的。驗收申請單每次只能驗收一類設備，但可能包括多個該類的設備，所以在入賬表單中需要根據該類設備的個數生成相應條數的子表數據。為了實現子流程間的數據傳遞，這里使用到了節點事件觸發器, 在子表加載前使用后臺程序將當前流程驗收完的設備信息加載到入賬申請單的子表中。入賬申請單子表中主要存放驗收完成的設備信息，如業務設計章節所述, 不同類型的設備在入賬時需要填寫的設備屬性信息是不同的。這一功能的實現是在前端頁面中使用JS代碼控制的。入賬子流程的最后一個節點需要填寫設備固定資產編號，為了保證設備資產編號的唯一性，在提交表單信息時會使用節點事件校驗資產編號。

設備入賬的目的就是把數據持久化到數據庫臺賬表和臺賬歷史記錄表中，所以為了實現數據的一致性和持久化，設備驗收入賬流程使用流程事件觸發器，當流程結束后觸發后臺程序，將走完入賬申請的設備信息同步到數據庫中。為了存檔，該流程也提供了表單打印功能，在流程結束后會出現打印按鈕，用戶可根據需要打印設備驗收入賬申請單存檔。

3.3.6其他資產入賬管理流程

目前航天所對于所有屬于設備類型里的設備都采用驗收入賬或直接入賬的流程來完成設備入賬，不過有些資產不屬于設備類型范疇，也不需要采購或驗收流程，根據這些設備的特殊需求，設計了其他資產入賬流程。該流程模型包括兩個B0數據表和一個表單。兩個B0數據表分別是其他資產入賬主表 (BO_SBGL_QTZCRZ_MAIN)和其他資產入賬表(BO_SBGL_QTZCRZ )。其他資產入賬流程模型如圖所示。該流程模型包括四個節點，且只有人工審核規則, 沒有系統規則，屬于比較簡單的業務流程。該模塊時序圖如圖3-19所示。主表中的信息自動生成，子表中的信息全部由用戶手動填寫，然后經過一系列審批將資產信息入賬到其他資產臺賬中。該流程的實現也使用到了數據校驗觸發器和流程事件觸發器，跟上述功能中介紹的觸發器類似，這里不再論述。

用戶普通用戶部門領導設備主管安全技術處主管

圖3T9其他資產入賬申請模塊時序圖

3.3.7設備直接入賬流程

設備直接入賬流程只適用于信息化部門，所以該功能模塊的訪問權限被授予信息化部門人員。具體的流程模型和流程節點與設備驗收入賬流程的后三個節點 -致，這里不再論述。該模塊的時序圖如圖3-20所示。

用戶普通用戶設備主管安全技術處主管

圖3-20設備直接入賬模塊時序圖

3.3.8設備領用管理流程

設備領用是指某部門的員工需要使用該部門的設備時，需要發出領用申請，經過各級領導審批通過后，設備儀器發放至申請人手中，申請人再對領到的設備確認。該功能是通過流程模型實現的。流程模型的實現包括兩個B0數據表和一個設備領用申請表單。兩個B0數據表包括設備儀器領用信息表 (BO_SBGL_LYXX)和設備儀器領用信息子表(BO_SBGL_LYXX_S)。該功能模塊的時序圖如圖3-21所示。申請人領用的是已入賬且未被使用的設備，用戶選擇需要領用的設備類型，找到目標設備。子表中設備信息的新增通過參考錄入實現，參考錄入也是一種數據字典，將當前用戶所在部門內的所有未被使用的設備且符合用戶想要的設備類型的設備全部查詢出來，用戶在查詢結果中選擇目標設備。參考錄入數組字典也是由SQL和@公式實現的。

當用戶對獲得的設備進行了確認，需要及時把被領用的設備狀態改為“在用” 狀態，其他用戶就不能再領用該設備了。這個功能點的實現是通過流程觸發器實現的。

用戶普通用戶部門領導設備主管普通用戶

圖3-21設備領用申請模塊時序圖

3.3.9特種設備、車輛管理

特種設備和車輛管理主要實現對設備檢定周期的管理,記錄設備上次檢查時間和有效期，從而計算出設備下次檢查的時間，并在下次檢查時間之前給用戶發送提醒消息，避免用戶忘記對設備檢驗。這兩個功能模塊的實現主要使用用戶報表來實現。特種設備各個子類型需要管理的屬性不同,但功能實現方式是一致的,

鍋爐管理如圖3-22所示，數據以網頁報表的形式展現。報表中的記錄是可以點擊修改的，用戶可根據需要點擊修改。車輛管理的功能實現類似于特種設備。

X- " " ，― —" ‘ 》" 1 ■ ■ ； "「 ” ” " —i 」「' 「•- 『’，一——；“，■ ”. —— 、

矮 |

- ISJf Hi刁邑：:-~ 麼: WE逐 ~. 8 | "9 一、£宀 *5

超重機械-特種設務養爹

i 企耘 •仝還寫r M廠已廂

2. i5S75o7f.-:-7^ ■L 療g宏汽二蘭 2017-03-15 2G17-B5

2. …芒:怒.. 2017-03-1? 2G17-Q5

圖3-22特種設備管理

3.3.10預報管理

預報主要是對車輛和特種設備檢定做提前預警通知，預報管理是對提前預警天數的設置。預警的方式包括消息提醒和郵件。該功能屬于信息維護功能，所以使用用戶視圖即可實現該功能。用戶視圖的實現包括兩個BO數據表和一個預報管理表單。BO數據表包括預報管理主表(BO_SBGL_YBGL)和預報管理子表 (B0_SBGL_YBGL_S)o預報管理表單及實現效果如圖3-23及圖3-24所示。

圖3-23預警時間設置

我的工作臺

* *- ” O Q

待力'枉務夫聞通敦已外查詢進夂瞳誼發起躍蹤委?右殳蚩 (56) ⑼

9蘭亍•:“"

吁范

* 9 WPdtW*的塗芻躍超呑斑泓趣規疑馳

2 © 3-W23423423ig§^B15i?

3它國餒爐預籃聖惑

£ * 曲爐翹警脫

5 * 叼鋸爐藏警鑿憾

8 ▽ ㈢鍋爐議辭惑

? ▽ 訥爐録辭鬆

e 0 田瞬預養諏

a ? ®鍋爐預欝艇

圖3-24預警功能實現效果

3.3.11基礎數據管理

在論述需求和設計模塊時，對基礎數據管理模塊的詳細功能己作介紹。該類功能屬于典型的數據信息維護的功能，所以使用用戶視圖即可。以資產類型維護功能的實現為例，如圖3-25所示。資產類型包括三級，在實現該功能時，使用三個數據表，設備類型和子類型數據表中的所有記錄都有父類型字段。

民［

?豈：-£7紹庇務屆◎&、=# 題m-衣篋m xr聲腫Trr冷3?曲”'、二p 匚 5=3^?

:;■?«

a匸媾

3^..雍=

■•二 3；.-SS^

，二 N 盪 CZS：：

z 7二"：•：»-總怎與-?- 蜜冬吳唸歴禺.＞、=磁:瘞圏T祿懣欲.藝灸.公5

■-二 •1SS2

2 : -S9 專主環金董

3.二:=S 確*雷

■i 二：9S B Bl

5 ■:: J&8

$ :.漓 ■5馭淞

7 二 MS it®?a 丿1

子煜曲妄；站碇琨夷筋曲籤＞

V；T- 滋 W=，零京國筈XSW邇W '弋3運醫皿盂爰狡、：-3

斕S2趕抄衣軒矣環

圖3-25資產類型維護

3.4本章小節

本章首先介紹了設備信息管理系統的各個模塊是如何設計的，自上而下的論述了概要和詳細設計。業務模塊貫穿了設備管理生命周期，在本章節中只介紹了本人負責的業務模塊。除了本章描述的業務模塊外，設備系統還包括資產管理、臺賬管理、在線考試等模塊。最后介紹了功能模塊的實現過程，介紹了流程建模、節點事件、流程事件等的實現過程。BPM Developer是基于Eclipse的集成開發工具，程序員將BPM開發過程中的共用接口和類進行封裝，提高了系統開發的效率及代碼的可重用性，是一種良好的系統開發技巧。

第四章系統安全機制的設計與實現

本章主要介紹了三部分內容。首先介紹了安全機制中的兩個核心研究點AES 算法的優化、基于多粒度組合的訪問控制策略；其次，介紹了系統安全機制的設計過程，論述了采用各個安全機制來保護系統安全的原理；最后，介紹了各個安全策略是如何實現的。

4.1AES加密算法的優化

本小節主要介紹原AES算法加密解密過程，并通過調研得出AES算法當前的優化改進現狀，進而提出了一種精簡AES算法，旨在提高AES算法加密速度。作者選擇將優化研究工作放在加密速度上而不是放在安全性上岀于兩個原因□ 一是設備信息管理系統實際運行環境為內網環境，研究所具有保密性，其物理環境、運行環境及網絡環境等為系統運行提供了天然的安全屏障，AES算法滿足企業對安全性的要求；二是設備信息管理系統的業務需求，隨著業務工作的增加，數據流量也會不斷加大，考慮到系統的響應速度、穩定性及處理數據的能力，把研究工作放在加密速度優化上是非常有價值、有意義的。本小節對原AES算法的加密過程進行了優化，并通過實驗數據對比優化前后的性能。

4.1.1AES加密過程的分析

AES (Advanced Encryption Standard)算法是由美國國家標準技術協會 (NIST)在2001年發布的加密標準PH。在通用技術小節中已介紹過各類算法的特點，這里詳細介紹AES算法。AES算法的分組及密鑰位數或為128bit、或為 192bit、或為256bit0高級加密標準規定，AES的密鑰位數可為三種長度，但AES 的分組位數被指定為128bit,但密鑰的長度可為以上三種長度中的任意一個。通過調研AES安全性論述文獻得出，AES算法常受到的分組密鑰的攻擊，包括窮舉攻擊、統計分析攻擊和數學分析攻擊QI。窮舉攻擊是對獲取的暗文使用所有的密鑰來破譯，嘗試得到有效的明文。或者使用同一密鑰對可能的明文進行加密，直到得到的暗文與獲取的暗文是一致的；統計分析攻擊是計算分析數據信息，獲得明文與暗文之間的聯系；數學分析攻擊是指破解者使用數學的方法并根據加密算法的數學依據來破解密碼，包括線性分析、差分分析等高等數學知識。從以上分組密鑰攻擊中可以得出，破解者均是對分組密鑰進行破譯，但由于AES算法采用密鑰擴展的方式，使得差異度較小的密鑰對在進行多輪擴展后，其差異度也會變得很大，所以基于AES加密的特點，AES算法能夠滿足內網系統數據的安全性需求。下面詳細論述AES算法的原理。

AES加解密算法（以128位為例）的過程如圖4-2所示。AES算法的計算過程需要十輪操作。以加密過程為例，前九輪的加密過程分別都需要四個子操作完成，第十輪的加密過程需要三個子操作完成。這些子操作被稱為加密算法中的輪變換。子操作中用到的輪函數如下介紹：

（1）非線性層混淆層，通過將原始字節數據進行字節變換（ByteSub）,混淆輸入的字節信息；

（2）線性混合層，通過行移位和列混淆實現高度擴散，且該操作在數據加密時會進行多輪操作，提高了暗文的復雜性和難破解性；

（3）密鑰加層，每輪操作都會進行輪密鑰加操作，目的是將輪密鑰處于中間狀態，提高密鑰的安全性。

在進行輪變換之前需要把明文轉變成密鑰的組織排列方式，即把一維結構數據轉變成二維數組，該數組可以代表AES算法的明文分組，也可以代表每次變換后的結果分組，我們可以把這個二維數組叫做狀態，即state,它通常為4*4 的矩陣，如圖4-1所示。

—171]—1[「| 寒「養 11111「箋盞||"||||

行移伍

密文

圖4-2 AES的加密和解密結構創

一、字節代替變換ByteSub

字節替代的主要是通過S-Box完成字節變換，將原字節替換為S-Box中的目標字節。簡單來說，就是根據原始字節查找表中對應的替代字節，即做一個非線性的字節變換。在這里以加密過程為例，介紹字節代替如何變換，假若要代替一個字節，首先要將這個字節轉換成兩個十六進制數，例如轉換后的結果為 0x19,則十六進制的“1”為行號，十六進制的“9”為列號，在S盒中位于“一行九列”的目標字節為，0xd4”，所以“0x19”通過S盒代替變成了“0xd4”。S盒的具體內容如圖4-3所示。

圖4-3 S盒內容

二、行移位變換ShiftRow

行移位是完成一個4*4矩陣內的字節轉換，目的是讓state中的每行達到一定的偏移量。如下圖4-4所示，在矩陣中，第i行循環左移(i-1)個字節，i為正整數，且 l=<i<=4o

■^0,1* S©莎 Sets" 鳳護 Se 皆

^1,2* Si’h 行移位 Si# 才 s燈兀護

$2才 s你 $2*

%於 s裁 &3才 S&g*3 $3工 S3左*

圖4-4 AES的行移位變換

三、列混淆變換MixColumn

列混淆是在GF (2A8)有限域上做乘法運算，目的是實現對state中各列進行混淆。在該過程中，state中的每一列被解釋為域GF(2A8)上的多項式，該多項式進行矩陣乘法并模M(x)=xA4+l,乘法矩陣用到的是常數多項式 c(x)=03*xA3+01 *xA2+01 *x+02,即下面所說的矩陣A。列混淆的原理圖如圖4-5 所示：

Sojf s打列混淆 s'檢 e -

A 0薩

Sy s’才 ^X2* ©I#1

^2# ^2,2^ 左乘矩陣A ^2,2*

^3# $3”屮 s實去気3+

圖4-5 AES的列混淆變換

矩陣A的內容如下所示:

02 03 01 01'

0102 03 01

A= 01 0102 03 '

.03 010102.

據矩陣的乘法，在列混淆的計算過程中，該列的四個值決定了每個字節相對

應的值。乘法與加法計算都是在GF (2人8)域上，需遵守以下規定：

(1)數值左移一位即為乘2。若數值首位為1 (從左至右)，則表示該值大

于等于128,還需將移位后的結果與Oxlb做異或計算；

(2)使用乘法分配律，舉例如下：

07-Sao = (01 ©02 ©04)-S闕=5ft0 ©(02• Sw)(04• SM) (4-1)

(3)輪變換過程中的矩陣乘法差別與傳統的矩陣乘法，矩陣中的值使用模

2加法(相當于用的是異或計算)進行相加。舉例論述計算過程如下：

02 03 0101

01 02 03 01

01 010203

L03 010102J L301 leSJ

Sfw = (02 • d4) ® (03 * bf) © (01 - 5d) @ (01 - 30) (4-2 )

其中：

(02 - d4) = 02-11010100s = 10101000g®00011011e = 10110011g

(03 - bf) =(01 © 02)• = 10111111^ © 01111110se00011011s

=11011010^

(01-5d) = 01-01011101B = OlOlllOlg

(01 - 30) = 01 - 00110000s = OOllOOOOg

則：

= 10110011s © llOHOlOg © 01011101B © 00110000fi = 00000100s =04

同理可計算出其他幾個值。

四、輪密鑰加變換AddRoundKey

每輪加密時，其輸入與輪密鑰異或計算獲得加工數據；每輪解密時，其輸入與輪密鑰異或計算即可獲得原值［23］。此過程用到了任何數與自身異或結果均為 0,且0與任何數異或計算后仍為任何數的原理。

在每輪的“輪密鑰加”操作中都會使用不同的密鑰來完成異或計算。每輪的密鑰都是通過擴展來實現的。AES128算法整體計算過程中使用了十一組密鑰。以加密過程為例，十一組密鑰的擴展過程如下：

第0組是加密算法的初始密鑰種子，第1組的密鑰是由第0組的密鑰計算轉換而來的。第n組的第i列的數據是第（n-l）組第i列的數據同第n組第（i-1）列數據的模2加，其中l=<i<=3。每組（從第一組開始）的第0列計算過程為：取前已組的第4列，并將其向左循環移動一個字節，然后對執行S盒替換操作，將替換后的四個字節與前一組的第一列及輪常量相加（十六進制加法），得到第0列的數據。

以上就是AES算法加解密的詳細過程。AES算法的加密過程包括十輪子操作，每輪子操作需要四個輪變換（第十輪需要三個輪變換），在尋找AES算法優化切入點時，考慮如下兩個問題：能否精簡AES算法加密過程的計算輪次、能否優化AES加密過程中每輪的輪變換操作。基于這兩個問題，在第四章將詳細論述對AES加密過程的優化。

4.1.2 AES算法優化方案的設計與實現

AES算法的特性滿足系統數據加解密的安全性需求，但考慮到隨著業務數據的不斷增加，在加密算法處理速度上可能會影響系統的反應速度，不能給用戶帶來較為流暢的使用體驗。為了優化AES算法的加密過程，調研了很多學者對 AES算法的優化方案。通過閱讀大量的參考文獻發現，數據經過AES算法的十輪計算和四次輪變換后的數據信息是暗文比較難被攻破的狀態，安全性已達到需求。如果在盡量不降低暗文復雜度的情況下，減少加密輪數及精簡每輪的輪變換過程，理論上是可以實現AES加密過程的優化。本文就調研結果提出了基于精簡輪次及整合每輪中操作的優化方案，即AES優化算法。下面詳細論述AES優化算法的設計與實現過程。

每輪的輪變換操作優化

據前述小節介紹，AES算法在每輪（不包含第十輪）的加密過程中均執行四個操作，其中行列操作都是對二維狀態矩陣的計算轉換操作，屬于數學計算上的問題。若將需要兩步的計算過程整合為一步計算，則將縮短計算所需的時間，所以可以將行移位和列混淆的計算過程整合為一個計算過程，但代價是空間復雜度比原來增加。優化后的AES算法的加密過程如圖4-6所示。

圖4-6 AES加密優化（將行列操作整合）

舉例說明行列操作整合過程。假設字節數據經過字節代替變換ByteSub后的結果為：

經過行移位ShiftRows和列變換MixColumn后，結果為:

則計算過程為:

那么矩陣M，中的第一行元素的計算過程為:

= 02Sm + O3Sos + 01Slo + 01S15,

S'©’ = 02Sgj 專（33$* "F 4* OXS垃,

S!Q2 = 02Sk + 03SQ7 + 01SO8 + OlSja, S'©3 = 02Sgg + 035^ OlSgg 4-

剩余三行元素的計算過程與第一行類似，有次我們可以發現矩陣M，的一維轉換矩陣M”為一個矩陣D與矩陣M的一維轉換矩陣Mi的乘積。如下所示：

則矩陣D中的行內容如下圖4-7所示。矩陣D是在AES優化算法中提供的一個類似于S盒的表，在源碼中通過二維數組來存儲。行列輪變換過程需要矩陣 D來完成計算。在行列組合計算的過程中涉及到了乘2和乘3的運算，乘2運算可以通過左移一位來計算，乘3運算可以通過先左移一位再與本身做異或運算來完成。但若數值首位為1,則左移后需與Oxlb做異或計算。

{0X020X00,0X00,0X00,0X0030X03,0X00}0X00,0X00,0X00,0X010X00J0x00,0X00,0X00,0X01}, {0X00^0X02,0X000X00,0X0% 0X00，0X03J0X00,0X00,0X00,0x00J0X01,0X01J0X00,0X00,0X00}彳 {0X00,0X00,0X02j0X00,0X00 J, 0X00,0X00J0閥3,0X01,0X00,0X00^0X00,0X00J0X01,0X00,0x00}, {0X00,0X00/0X00；0X02,0X0330X00,0X00J0X00,0X00,0X01,0X00^0X00,0X00,0X00,0X01,0X00}, {0X^10X00,0X00J 0X00,0X00J0X0乙 0X00,0X00,0X00,0x00,0X03., 0X00J 0x80,0X00,0X00^0X01}^ {0X00,0X01> 0X00,0X00,0X00^0X00^0X02,0X00,0X00,0X00,0X00,0X03,0X0130X00,0X0030X00}t {0X00,0X00,0X01,0X00,0X00J0X00,0X00,0X02,0X03J0X00,0X00,0X00,0X00,0X01,0X00J 0X00}, {0X00,0X00,0X00,0X01,0X02,0X00,0X00?0X00J0X00J0X03,0X00,0X00,0x00,0X00,0X01,0X00}, {0X01,0X00,0x00J0X00,0x00,0X01^0X00,0X00,0X00,0X00,0X02^0X00,0X00,0X00,0x00,0X03}, {0X00，0X0130X00J0X00,0X00,0X00,0X01? 0X00,0X000X00,0X00* 0X02,0X03,0X00,0X00J0X00}, {0X00,0X00^0X01^0X00,0X00,0X00,0X00^0X01,0X02^0X00,0X00,0X00,0X00^0X03,0X00,0X00}J {0x00,0x00,0x00,0x0130x01,0x00,0x00j0x00 j0x00,0x02,0x00,0x00,0x00,0x00,0x0330x00} {0X0330X00,0X0030X00,0X00J0X01,0X00J0X00J 0X0G,0X00,0X01J 0X00J0X00,0X00,0X00,0X02}J {0x00j0x03,0x00,0x00,0x00,0X00,0x0190x00,0x00,0x00‘ 0x00,0x01,0x02,0x00,0x00,0x00}, {0X00,0X00}0X0330X00,0X00,0X00,0X00,0X01丿 0X01s 0X00,0X00s0X00,0X00J 0X02,0X00，0X00}, {0X00,0M0# 0X00J0X03,0X01^0X00,0X00,0X00J0X00,0X01,0X00J0X00,0X00,0X00,0X02,0X00}

圖4-7矩陣D中每行的內容

按照優化方案編寫代碼發現，AES加密時間確實減少了。優化前后的AES 算法使用相同的密鑰對多個長度不等的數據進行加密，并且測試前提是優化前后的算法每次只對同一個數據進行加密。經過大量的測試，優化前后消耗的平均加密時間對比結果如表4-1所示。從表中數據可以發現優化后的算法對同一數據的加密速度更快，所需時間更少。

表4-1 AES算法采用輪次內優化平均加密時間對比

序號優化前耗時（ms）優化后耗時（ms）消耗時間差值（ms）

1 1.0 1 0.5 0.5

2 3.4 I 2.9 0.5

34.8 : 3.9 0.9

47.3 6.1 1.2

513.3 8.2 5.1

二、輪次優化

AES加密算法設置十輪加密的原因加密過程中處理數據的輪次越多，數據越復雜，越不容易被破解，安全性越高，但考慮到時間復雜度和空間復雜度，也并不是輪次越多越好，所以輪次優化旨在查找一個少于十輪的輪次，且其復雜度相當于第十輪。調研得知的AES優化方案中，有學者提出了 AES輪次精簡的方案，且該方案的提出是在已確定AES-128算法只能在六輪以下的精簡計算版本下受到捷徑攻擊，六輪以上的加密過程可抵御已知的捷徑攻擊BI。所以，輪次優化方案從密鑰擴展情況及AES算法執行六輪及六輪以上的時間復雜度分析確定優化結果。

兩個不同的密鑰經過幾輪的密鑰擴展，密鑰之間的差異度會越來越大，假若惡意用戶揣測到與真實密鑰相似度比較高的密鑰，但隨著輪次的增加，密鑰的差

異度會增大，AES算法不容易被攻破。下面就以幾組相似的密鑰對為例，比較經過多輪密鑰擴展操作后，相似密鑰之間的差異度會如何變化，如表4-2所示。

表4-2相似密鑰對

序號密鑰1 密鑰2

1 1A 09 EF 76 CC 18 29 33 06 21 AB DD

6E3AFF AD 1A 09 EF 74 CC 18 29 33 06 21 AB

DD 6E 3A FF AD

2 08 BB AA CC 56 6C 7A C8 11 DD 03 29

44 3B AC DF 08 BB AA CC 56 6C 7A 88 11 DD 03

29 44 3B AC DF

3 22 DC AA 03 Fl D5 77 32 FC AC A5 F6

40 06 55 CA 22 D4 AA 03 Fl D5 77 32 FC AC A5

F6 40 06 55 CA

4 00 1A BB 3A 1C DC AF DD 01 F9 C4 6D

33 29 0A Fl 00 1A BB 3A 1C DC AF DD 01 F9 C4

6D 33 29 0A F0

5 22 65 9D CC 4A 2B 86 9B 11 CF A8 99

BD AB7F80 22 64 9D CC 4A 2B 86 9B 11 CF A8

99 BD AB 7F 80

上表中，密鑰一與密鑰二不同的位都用下劃線標識出來了，這里我們將兩個密鑰含有多少個不同的比特位稱為密鑰差異度，上表中的所有密鑰對的初始差異度均為1。下面對密鑰對的擴展過程及差異度變化作詳細論述。

1.第一對相似密鑰經過10輪擴展后的結果如下表4-3所示。

表4-3第一對相似密鑰的差異度

RD 密鑰1 密鑰2 差異度

0 1A 09 EF 76 CC 18 29 33 06 21

AB DD6E 3AFFAD 1A 09 EF 74 CC 18 29 33 06 21

ABDD6E3AFFAD 1

1 9B IF 7A E9 57 07 53 DA 51 26

F8 07 3F 1C 07 AA 9B IF 7A EB 57 07 53 D8 51 26

F8 05 3F 1C 07 A8 4

2 05 DA D6 9C 52 DD 85 46 03 FB

7D413C E7 7AEB 05 DA B8 9E 52 DD EB 46 03 FB

13 43 3C E7 14 EB 22

3 95 00 3F 77 C7 DD BA 31 C4 26

C7 70 F8 Cl BD 9B 95 20 51 75 C7 FD BA 33 C4 06

A9 70 F8 El BD 9B 16

4 E5 7A 2B 36 22 A7 91 07 E6 81

56 77 IE 40 EB EC 65 5A 45 34 A2 A7 FF 07 66 Al

56 77 9E40EB EC 17

5 FC 93 E5 44 DE 34 74 43 38 B5

22 34 26 F5 C9 D8 7C B3 8B 3F DE 14 74 38 B8 B5

22 4F 26 F5 C9 A3 33

6 3A 4E 84 B3 E4 7A F0 F0 DC CF

D2 C4 FA 3A IB 1C BA 6E 81 C8 64 7A F5 F0 DC CF

D7 BF FA 3A IE 1C 23

（續上表）

RD 密鑰1 密鑰2 差異度

7 FA E1 18 9E IE 9B E8 6E C2 54

3A AA 38 6E21B6 7A 1C ID E5 IE 66 E8 15 C2 A9

3F AA 38 93 21 B6 45

8 E5 1C 56 99 FB 87 BE F7 39 D3

84 5D 01 BD A5 EB 26 El 53 E2 38 87 BB F7 FA 2E

84 5DC2BDA5EB 40

9 841A BF E5 7F 9D 01 12 46 4E

854F 47 F3 20 A4 47 E7 BA C7 7F 60 01 30 85 4E

85 6D 47 F3 20 86 32

10 BF AD F6 45 CO 30 F7 57 86 7E

72 18 Cl 8D 52 BC 7C 50 FE 67 03 30 FF 57 86 7E

7A 3A Cl 8D 5A BC 23

2.第二對相似密鑰對經過10輪密鑰擴展后的結果如下表4-4所示。

表4-4第二對相似密鑰的差異度

RD 密鑰1 密鑰2 差異度

0 08 BB AA CC 56 6C 7A C8 11 DD

03 29 44 3B AC DF 08 BB AA CC 56 6C 7A 88 11 DD

03 29 44 3B AC DF 1

1 EB 2A 34 D7 BD 46 4E IF AC 9B

4D 36 E8 AO El E9 EB 2A 34 D7 BD 46 4E 5F AC 9B

4D 76 E8 AO El A9 3

2 09 D2 2A 4C B4 94 64 53 18 OF

29 65 F0 AF C8 8C 09 D2 E7 4C B4 94 A9 13 18 OF

E4 65 FO AF 05 CC 22

3 74 3A 4E CO CO AE 2A 93 D8 Al

03 F6 28 0E CB 7A 74 B9 AC CO CO 2D 05 D3 D8 22

El B6 28 8D E4 7A 32

4 D7 25 94 F4 17 8B BE 67 CF 2A

BD 91 E7 24 76 EB 21 DO 76 F4 El FD 73 27 39 DF

92 91 1152 76 EB 61

5 Fl ID 7D 60 E6 96 C3 07 29 BC

7E 96 CE 98 08 7D 31 E8 9F 76 DO 15 EC 51 E9 CA

7E CO F8 98 08 2B 50

6 97 2D 82 EB 71 BB 41 EC 58 07

3F7A 96 9F 37 07 57 D8 6E 37 87 CD 82 66 6E 07

FC A6 96 9F F4 8D 56

7 OC B7 47 7B 7D OC 06 97 25 OB

39 ED B3 94 OE EA CC 67 33 A7 4B AA Bl Cl 25 AD

4D 67 B3 32 B9 EA 53

8 AE 1C CO 16 D3 10 C6 81 F6 IB

FF 6C 45 8F Fl 86 6F 31 B4 CA 24 9B 05 OB 01 36

48 6C B2 04 Fl 86 62

9 C6 BD 84 78 15 AD 42 F9 E3 B6

BD 95 A6 39 4C 13 86 90 FO FD A2 OB F5 F6 A3 3D

BD 9A 11 39 4C 1C 51

（續上表）

RD 密鑰1 密鑰2 差異度

10 E2 94 F9 5C F7 39 BB A5 14 8F

06 30 B2 B6 4A 23 A2 B9 6C 7F 00 B2 99 89 A3 8F

24 13 B2 B6 68 0F 44

同理可得其他三組的差異度，如下表4-5所示。

表4-5其他三對相似密鑰的差異度

密鑰對差異度

22 DC AA 03 Fl D5 77 32 FC AC A5 F6 40 06 55 CA

22 D4 AA 03 Fl D5 77 32 FC AC A5 F6 40 06 55 CA 1,4,14,24,31,43,44,46,38,41,29

00 1A BB 3A 1C DC AF DD 01 F9 C4 6D 33 29 0A F丄

00 1A BB 3A 1C DC AF DD 01 F9 C4 6D 33 29 0A F0 1,17,25,45,63,61,56,56,65,75,63

22 65 9D CC 4A 2B 86 9B 11 CF A8 99 BD AB 7F 80

26 65 9D CC 4A 2B 86 9B 11 CF A8 99 BD AB 7F 80 1,4,18,34,33,38,40,29,34,33,34

根據以上五組差異度的計算結果，作出折線圖分析出輪次對密鑰對差異度值的影響，如圖4-7所示。

圖4-7相似密鑰對隨輪次擴展的差異度對比

從折線圖中可以發現，隨著輪次的不斷增加，初始密鑰對（初始差異度為1）的差異度越來越大，且有的密鑰對在第四到五輪時，差異度會有下降的趨勢，但在后面的輪次中差異度依然會有上升的趨勢，所以，從整體來看第六輪的密鑰差異度確實且達到了類似于與第十輪的差異度的結果，該實驗也驗證了 AES-128 算法在六輪以上不容易被捷徑攻擊給攻破，實驗驗證的結果是理論上只需要六輪操作即可確保AES算法的高安全性，考慮到AES優化方案不能影響原安全性，故將進行七輪操作，第七輪作為安全余量。對同一數據進行六輪以上輪次操作的時間消耗如表4-6所示。從表中數據可以看出，隨著輪次的增加，AES算法對同一數據加密所需的時間越長，且第七輪的加密時間比第十輪的加密時間減少28% 左右。所以輪次優化可以實現減少加密時間的目的。

表4-6 AES算法采用不同加密輪次平均消耗時間對比

總輪數平均消耗時間(ms)

6 1.7

7 1.8

8 2.0

9 2.1

10 2.5

綜上所述，在AES算法中采用了減少輪次的優化和整合輪次內操作的優化。將兩個AES優化方案進行整合并代碼實現，通過采用大量數據進行測試實驗，優化前后的AES算法加密時間部分測試數據如下表4-7所示。

表4-7優化前后AES算法加密過程平均消耗時間對比

NO 原AES加密時間(ms) 優化后AES加密時間(ms) 結果分析

1 2.5 1.3 減少48.0%

2 1.0 0.6 減少40.0%

3 2.2 1.2 減少45.4%

4 1.1 0.4 減少63.6%

5 1.9 0.9 減少52.6%

平均減少49.9%

以上結果顯示，通過對AES加密算法的輪次和輪次內操作進行優化，能夠提高AES算法的加密速度，進而提高系統處理數據的速度。實驗證實可以對AES 的加密過程進行優化，其安全性需要持保守態度。所以，對于敏感性低的數據可以使用優化的AES算法；但安全性要求高且數據量較大時，還是采用AES算法, 確保大量敏感數據受到高安全性的保護。

AES優化主要是對加密過程的輪次和輪次內的操作進行優化，優化后的偽碼如下所示。

char[] cipher_vl(char[] input) {

//輸入內容由一維轉換為二維

〃輪密鑰加

fbr(i=l;i<=7;i++){//i為輪次，只需進行7輪操作

〃字節代換；

if(i!=7){

RCTransfer(state);// 行列轉換

}

if(i=7){

.……〃行移位

}

〃輪密鑰加

}

〃加工返回數據

return input;

}

4.2基于多粒度組合的訪問控制策略

訪問控制(AccessControl),是一種用來控制資源訪問權限的策略。訪問控制包含三個核心元素：主體，客體及授權訪問。關于訪問控制策略的發展歷程已在2.1.5小節中介紹。本小節詳細介紹了基于角色和基于任務的訪問控制，并在分析了通用策略后，根據系統業務需求提出了一種基于多粒度組合的訪問控制策略，旨在實現授權范圍從大到小的靈活授權服務。

4.2.1通用訪問控制策略的分析

通過調研大量文獻，管理系統的授權控制多采用基于角色和基于任務的訪問控制，另外還包括基于用戶組的訪問控制(GBAC, Group-Based Access Control 基于用戶的訪問控制(UBAC, User-Based Access Control)等。根據各控制策略在系統建設中的占比，該小節主要介紹基于角色、用戶組的訪問控制。

1.基于角色的訪問控制(RBAC)

該技術是在上世紀九十年代初由David Ferraiolo> Rick Kuhn提出的，后來 Ravi Sandhu提出了 RBAC理論的主體架構，為訪問權限中的授權管理問題提出了新的解決方案©J這種主題架構的提出改善了原來用戶-權限的兩層結構，加入了角色作為中間代理，形成了用戶-角色-權限三層結構，權限包括操作和資源兩個部分。RBAC是將系統中操作資源的權限指派給角色，這種結構降低了權限與用戶的耦合性，使得權限控制更加靈活，可擴展性較高。

RBAC模型設計時需要遵循以下原則：

（1）授權最小化。用戶或計算機程序只能訪問其必需的信息或數據資源，實現授權最小化，避免授權過大造成資源的惡意破壞；

（2）角色繼承。為了提高角色的利用率，規定子角色可通過繼承獲取父角色所具有的權限，增量實現角色的權限擴展，提高效率［26〕；

（3）角色容量。“所長”只能由一人擔當，組織結構中的某些角色僅限一定數量的用戶來擔任，所以要限制角色的最大支持用戶數量。

（4）職責分離。為了防止主體借助多權限造成的管理漏洞而差生惡意行為, 需要規定一些互斥的約束條件，規定某些權限在一定條件下進行行使。該原則保證了權限敏感系統的安全性。

RBAC模型的定義表4-8所示。

表4-8 RBAC模型定義

符號定義說明

S Subject 訪問主體、用戶或者自動化代理程序

R Role 角色，指派給用戶并定義用戶權限級別

P Permission Ji限，定義訪問資源許可

SE Session 包括S、R、P在內的一次會話

SA Subject Assignment 主體分配

PA Permission Assignment 權限分配

RH Partially ordered Role

Hierarchy 表示角色繼承偏序關系，也可以記為2”，例如a^b, a繼承了 b的所有權限

RBAC模型由用戶、角色和權限組成，其授權規則如下：

（1） “角色-權限”授權。權限直接標識了哪些資源允許訪問，且需要將權限授權給角色，角色才能將權限賦給用戶，有權限的角色才是有意義的。

（2） “用戶-角色”分配。將角色賦予某一用戶，實現權限的間接授權。

（3）授權許可。在前兩個規則的約束下，第三個規則規定了用戶只有擁有了授權許可后，才能訪問相應資源〔271。

根據RBAC授權規則，得出以下授權規定：

（1） PA £ P X R即權限分配與角色屬于"many to many"的關系；

（2） SAC S XR即主題分配與角色屬于“manttomany”的關系；

（3） RHC RXR即角色繼承實現了角色間的偏序關系。

以上規則解釋為：

（1）一個主體可以對應多個角色；

（2）一個角色可以對應多個主體；

（3）一個角色可以擁有多個權限；

（4）一個權限可以對應多個角色；

（5）一個操作可以對應多個權限（許可）；

（6）一個權限（許可）可以對應多個操作。

RBAC模型圖如圖4-8所示。

2.基于任務的訪問控制（TBAC）

基于任務的訪問控制是通過指定任務的訪問規則，完成用戶對任務的授權操作，主要是面向任務授權。基于任務的訪問控制被廣泛應用于基于工作流驅動的業務中［28］。TBAC不同于RBAC,在授權上具有粒度小的特點，能夠將授權控制到較小單元。TBAC作用在工作流程中時，包括以下基本概念。

（1） Authorization Step （授權節點）。授權操作包含了操作委托辦理人（主體）及操作集（客體）。當授權節點被實例化后，操作委托辦理人就具備了操作集中所有操作的執行權限。

（2） Authorization Unit （授權結構體）。授權結構體是多個節點的集合，節點間具備邏輯聯系。我們可以把流程實例的授權看成一個授權結構體，一個流程實例中包含多個任務節點，授權結構體內的授權節點都是按照流程審核規則依次執行［2刃。如果有一個授權節點的執行失敗，則授權結構體是無法繼續執行下去的，只有上一個授權節點執行成功，流程才能繼續執行。

（3） Task （任務）。任務是工作流程中的一個節點，該節點的授權執行者可能有多個，該節點也可能會執行并簽操作。在實際業務環境中，任務節點是長期存在的，一般不會被銷毀、任務節點可以包含多個子節點（觸發子流程）、任務節點的辦理者可能包括多個辦理人（并簽）。

(4)Dependency (依賴)。依賴是指授權節點與授權結構體之間相互依賴，授權結構體的實現依賴于授權節點，授權節點只有存在于授權結構體中才能被執行。授權節點之間在授權結構體中具有順序性，而授權結構體執行成功與否依賴于所有授權節點的執行結果。

TBAC授權模型的定義如表4-9所示。

表4-9 TBAC模型定義

符號定義說明

S Subject 授權主體

O Object 授權客體

P Permission 權限，定義訪問資源許可

L LifeCicle 生命周期

AS Authorization Step 授權節點

在授權節點被激活前，授權結構體還沒有執行到該授權節點，屬于休眠狀態; 當授權節點被激活后，授權節點的執行者就具有了執行該任務節點的權限，同時, 任務節點的生命周期開始倒數，當授權節點被指定的執行者辦理完畢后，節點的生命周期清空，執行者失去執行該節點的能力。由于被激活的工作流實例處于活動狀態，所以授權節點不是靜止不動的，而是隨著業務邏輯在不斷跳轉執行。授權Step的狀態變化如圖4-9o

圖4-9 TBAC授權節點狀態轉換

在航天設備信息管理中大部分業務都是基于工作流模型的，在復雜的工作流程中包含多個任務節點，每個任務節點的辦理人選擇和路由方案可能不同。通過對業務需求的深入分析，流程節點的執行者有根據用戶角色指定的，也有根據任務指定的，還有其他指定方式。如果僅僅使用其中一種或者兩種授權策略，不能滿足多粒度訪問控制的需求，進而無法實現嚴謹的訪問控制。故在以上兩種訪問控制能夠策略的基礎上，提出了一種多粒度組合的訪問控制方案。

4.2.2基于多粒度組合的訪問控制方案的設計與實現

1•基于多粒度組合的訪問控制方案的設計

該方案是一種針對航天設備管理系統提出來的一種的訪問控制方案。該方案的提出有兩個原因，其一是系統實際業務流程繁多且流程審計規則較為復雜，使用單一的訪問控制策略無法很好地控制資源訪問權限；其二是為了提高系統資源授權的靈活性，采用多粒度的授權規則，能夠滿足管理員不同用戶、用戶組或角色的人員授予相應的權限，減少規則約束而導致授權操作的局限性。

基于上述兩種訪問控制方案，還結合了基于用戶的訪問控制(UBAC, User-Based Access Control)和基于用戶組的訪問控制(GBAC, Group-Based Access Control)策略基于角色、用戶組、任務的訪問粒度將作為流程任務節點的授權規則，基于用戶的粒度將作為用戶使用終端機器登錄系統的授權規則。下面詳細介紹多粒度組合的控制方案應用場景。

基于角色的訪問控制。例如采購申請流程中的前兩個節點分別是普通用戶填寫申請表單、部門領導審批申請信息，所以利用RBAC訪問控制方式就比較適合。第一個節點的辦理角色選擇普通用戶，第二個節點的辦理角色選擇部門領導。假設用戶A為普通用戶，那么用戶A就可以執行采購流程的第一個節點；假設用戶B為部門領導，那么用戶B就可以執行采購流程的第二個節點。用戶A不能辦理審批任務，用戶B也不能發起流程。該種方案不需要基于用戶授權，只需將權限賦予角色，指定用戶屬于哪種角色，間接授權。

基于用戶組的訪問控制。在設備領用時，普通用戶只能申請領用該部門的設備資源，所以某一部門的資源只能由該部門的人訪問，其他部門的人員不能訪問。由于航天所設備信息管理系統涉及多個部門的人員，所以使用基于用戶組的訪問控制可以方便部門內資源管理，避免資源管理混亂。

基于用戶的訪問粒度是規定某一用戶使用某一 IP的終端機器獲取應用系統信息。若指定賬號及對應IP,當員工登錄到設備系統時會獲取終端設備的IP, 并判斷此IP是不是該賬號對應的IP,若是，則允許用戶訪問系統；否則，不允許用戶登錄系統。

基于任務的訪問粒度是指定某些任務節點由某一用戶執行。例如在設備領用申請流程中，用戶A發起領用申請，則在流程審批后到達最后一個節點時需要用戶A對領用的設備進行確認，所以這個設備領用確認的任務需要由A用戶來完成。基于多粒度的訪問控制如表4-10所示，表中詳細描述了各個粒度的授權規則特點及適用場景等。

表4-10多粒度的訪問控制

訪問控制粒度特點適用場景舉例

RBAC 較大授權方便

管理靈活適合指左節點辦理人辦理所有流程的第一個

節點使用普通用戶角色

GBAC 大管理靈活

粒度適中適合指定部門級資源訪問及節點辦理部門人員只能訪問本部門資源

UBAC 小將訪問控制

細化到個體適合指定個人

級資源訪問指定賬戶由某一固定IP 訪問資源

TBAC 小將任務細化

到任務節點適合指定任務

辦理人流程最后一個節點需要

有流程發起人辦理時

當然，該方案并不是適合于所有信息管理系統的訪問控制，在選擇訪問控制方案時，需要以系統實際需求為主。多粒度的訪問控制也有不易管理的不足之處, 但由于其覆蓋全面、授權靈活的特點符合航天所訪問控制的實際需求，所以利大于弊。

2.基于多粒度組合的訪問控制方案的實現

基于角色、用戶組、任務粒度的方案將作為任務節點的授權規則，通過制定流程節點路由規則，指定每個節點的授權訪問方式。通過實現 ParticipantRoutelnterface接口，在routeUser()方法中指定該任務節點使用哪種訪問控制策略。如果使用RBAC策略，則在routeUser()方法中校驗當前用戶是否為授權執行的角色，若校驗通過，則允許該用戶辦理該任務節點，否則不允許辦理; 如果使用GBAC策略，則在routeUserO方法中指明由哪些用戶辦理該任務節點, 當授權節點被執行時，檢驗辦理者是否為授權人，若校驗通過，則允許辦理，否則不允許辦理。同理可在routeUser()方法中實現基于TBAC的訪問控制策略。

基于用戶的訪問控制作為用戶使用終端機器登錄系統的授權規則，即某一用戶必須使用某一 IP的終端機器登錄系統，否則不允許登錄系統，該策略適合于管理員的訪問控制。管理員屬于特殊角色，權限相對較大，若普通用戶獲得管理員的登錄終端的USB Key,則可以在自己的終端機器上登錄系統，UBAC策略就是防止了這種漏洞的存在。該策略的實現主要通過登錄適配器來實現。登錄適配器實現了 Logininterface接口，核心方法為login()方法，該方法返回執行操作結果狀態碼。參數列表如下表4-11所示，其中LoginContext為用戶登錄上下文狀態類，LoginContext類包含多個獲取上下文信息的方法,getlp()方法用于獲取用戶的登錄IP,通過與數據庫中當前用戶對應的IP進行匹配，即可斷定當前用戶是否用指定IP登錄系統，基于用戶的訪問控制即可實現。

表4-11 login ()方法參數列表

參數名 LoginContext 方法說明

LoginContext getMD5Pwd() 明文口令被MD5加密后的暗文

getlp() 登錄客戶端的IP地址

getPwd() 用戶明文口令

getUid() 用戶輸入的賬戶名

getParam(str) 擴展參數

4.3安全機制-密級標識

4.3.1密級標識機制設計

用戶的密級標識對應用戶的其中一個屬性，所以在用戶表中創建一個字段來表示用戶密級。用戶的密級標識需要由管理員來設置，用戶對自己的密級標識是只讀狀態。非密級別的用戶一般是流程發起人，主要工作是提出申請；秘密級別的用戶一般是流程的審批人，主要工作是審批普通用戶提出的申請；機密級別的用戶一般是流程審批中職級最高的領導，主要工作是最終決定申請是否通過。

數據密級標識主要用來標識數據實體的密級，數據實體主要包括敏感字段、涉密表單、涉密流程。不同級別的角色其密級不同，密級標識在授權控制中起到輔助作用&叭例如，特種設備型號只允許設備儀器主管瀏覽，普通員工不能瀏覽。在展現表單信息前，會獲取當前用戶的角色，若當前用戶的角色為設備儀器主管，那么表單中允許顯示特種設備型號；若當前用戶的角色為普通用戶，則表單中不會顯示特種設備型號。敏感字段在存儲時也會使用AES加密算法進行加密。

涉密表單主要采用在主表中創建標識表單密級的字段。實例中一般包括主表、子表和節點審批過程記錄。一個表單中只包含一個主表，可以包含多個子表。主表一般是用于表示當前流程實例的申請人、申請單號等信息，子表一般用于存儲多行信息，例如購置申請表單中需要申請多種類型的設備，那么就需要子表來存儲這些設備信息。表單中多個表的數據聯系由實例的BindID記錄。每個流程實例都有唯一的BindIDo節點審批信息是指當前節點之前節點的審批信息，其主要作用是記錄流程節點的詳細審批信息，具有存檔的作用。所以使用主表中的一個字段來表示表單的密級標識即可。

涉密流程的密級使用流程表中的一個字段表示。流程實例表中由UUID、實例名稱、模型分類、模型管理員、密級標識、流程執行時間范圍、流程是否允許作廢、流程描述、流程是否已關閉等組成。

4.3.2密級標識機制實現

密級標識包括數據密級標識和用戶密級標識，在功能設計模塊中介紹了通過數據庫表字段標識實體密級。用戶密級標識通過在用戶表中添加密級字段即可，如圖4-10用戶表的ER圖所示；流程密級標識使用流程實例數據表中的密級字段標識，與表單密級實現方式相同，如圖4-11流程表的ER圖所示。

圖4-11流程表ER圖

密級在數據庫中以int型存儲。用數字0代表非密，數字1代表秘密，數字 2代表機密。用數字類型代替字符類型是為了減少占用內存空間，在對密級標識進行加密時效率會更高。

4.4安全機制-敏感數據加密

4.4.1數據加密方案設計

航天設備信息管理系統中包含秘密設備的信息，需要對系統中的敏感數據加密存儲。在選擇加密算法時，不能從一般信息系統的角度去考慮，而要從系統實際運行環出發，選擇合適的技術。航天研究所提供了內網環境，所有人員不得連接外網，這樣的規定對數據的安全提供了天然的保護屏障；航天研究所的所有終端設備都加入了基于局域網建立的AD域，所有人員登錄終端設備都需要通過 USB Key進行身份認證；所有員工不得在工作區域攜帶手機等電子設備，避免惡意用戶通過拍照等方式泄露數據。在技術小節中已經論述使用AES128算法對系統數據加密，使用SHA-1算法對密級標識加密。敏感數據加解密過程如圖4-12 所示，數據加密的處理主要在Model層實現，數據展現的處理也是在Model層處理之后，返回至Controller層，并最終由Controller層返回到View層。

圖4T2敏感數據加解密過程

4.4.2數據加密方案實現

目前，由針對SHA-1和AES算法的java包提供數據加工處理服務，只需通過調用工具包封裝數據處理方法即可實現數據的加密和解密。以AES為例，后臺程序在向數據庫中存儲敏感數據之前，調用AESUtiLencryptO函數對敏感數據加密；后臺程序想前端頁面發送敏感數據之前，調用AESUtil.decrypt()解密函數解密。

在技術章節中，提到了使用優化的AES算法對數據進行加密，AES算法優化前后的性能對比已在第三章中介紹過，這里不再敘述。雖然經過調研和實驗驗證經過輪次優化和輪次內操作優化確實可以在保證安全性的基礎上提高AES算法的加密速度，但這只是實驗范圍內及理論上的結果，如果在將來有威脅AES 算法安全性的技術出現，加密算法的速度要求就會低于安全性要求，可能還必須采取穩定的十輪加密操作來確保敏感數據的安全性，這也是加密算法的最終目標。基于以上思考，可對一些安全性要求不高、數據量較大的數據采用優化的 AES算法，對于敏感性較高的數據采用原始的AES算法。

使用原始的AES算法進行加解密可以通過調用javax.crypto.Cipher和 javax.crypto.spec.SecretKeySpec類中的方法來實現，同時還需要引入 commons-codec-1.8.jar 來調用 org.apache.commons.codec.binary.Base64 里的類方法實現轉碼功能，BASE64也起到了二次加密的作用。偽碼如下：

import javax.crypto.spec.SecretKeySpec;

import javax.crypto.Cipher;

import org.apache.commons.codec.binary.Base64;

/**

* @AES-128加密、解密

class AES {

〃加密

String加密（明文，密鑰）{

.......〃判斷密鑰是否為空

•……〃判斷密鑰是否為十六位

.••••••〃將密鑰通過“UTF-8"編碼方式編碼，獲取字節數組

•……〃調用SecretKeySpec（密鑰字節碼,”AES”）構造函數，獲得密鑰對象

〃調用Cipher的getlnstance（）方法獲取加密實例

…….〃調用實例初始化函數init（加密模式,密鑰）

…•…〃調用實例doFinal（明丈getBytes（“UTF-8”））方法獲取字節數組暗文

.......//返回經過Base64編碼后的字符串，即為最終的暗文

}

〃解密

String解密（暗文，密鑰）{

•••••••〃判斷密鑰是否為空

〃判斷密鑰是否為十六位

•……〃將密鑰通過“UTF-8”編碼方式編碼，獲取字節數組

•••••••〃調用SecretKeySpec（密鑰字節碼,”AES”）構造函數，獲得密鑰對象

〃調用Cipher的getlnstance（）方法獲取加密實例

•……〃調用實例初始化函數init（解密模式,密鑰）

.......〃先用base64解密得到中間態暗文

….…〃調用加密實例"Final仲間態暗文）方法獲取字節數組明文

.......〃使用new String（字節數組明文,”UTF-8"）,獲取明文

}

測試結果如下表4-12所示。

表4-12原AES算法加解密測試

NO 字符串加密結果解密結果

1 特種設備檢定周期 BFQjc+kivpFareiqhmrOFSFd7E

JWXrezwBRHv6Dnfin4= 特種設備檢定周期

2 機密文件 sIllEWjSwNfl99Y+kCwqyA= 機密文件

3 6222 0879 6759 1

556 mSKLAoNzNkPBTQIJtTFfiUXtVj

HAyPQ+NLlb/io/OI= 6222 0879 6759

556

4 testEmail@qq.com blEOx4fWOO/virecf4ARCCqnNu

HKXZ5nXxt54Xwa7uA= testEmail@qq.com

4.5安全機制-身份認證機制

4.5.1基于AD域的身份認證設計

為了保護資源安全，防止資源被濫用，航天所要求所有的終端機器都必須加入到域林中。活動目錄（AD） Microsoft為Windows域網絡開發的目錄服務，常作為一組流程和服務作用于Windows服務器操作系統中。最初，活動目錄只負責終端機器集中域管理，但從2008年開始，活動目錄廣泛應用于身份認證相關的服務中。提供AD域服務的域控制器用于驗證Windows域中的所有用戶和計算機身份，并實現授權服務，為所有計算機分配和實施安全策略，并安裝或更新軟件。例如，當用戶登錄到屬于Windows AD域的計算機時，活動目錄會檢查提交的密碼，并確定該用戶是系統管理員還是普通用戶。此外，它還允許建立部署其他相關服務的框架，包括證書、聯合及輕量級目錄服務（Lightweight Directory Access Protocol, LDAP）等，其中LDAP常用于系統組織結構的統一化管理中，下面詳細介紹LDAP目錄服務。

輕量級目錄服務，簡稱為LDAP,是開放的行業應用協議a】。目錄服務通過允許在整個網絡中共享有關用戶、系統、網絡、服務和應用程序的信息，在互聯網開發和Internet應用程序方面發揮著重要的作用。例如，企業電子郵件目錄結構可以使用目錄服務實現記錄集。輕量級目錄服務中的數據是按照對象的屬性進行結構安排的，并存在于條目中，條目類似于數據庫中的表記錄［3現每個條目都有標志性屬性值，該屬性值為區別名DN,相當于數據庫表中的主鍵。條目的屬性由Type （類型）和Values （多個值）組成。為了方便檢索的需要，LDAP 中的類型可有多個值，這一點與關系型數據庫降低冗余性的操作意義不同。

通過AD域，將航天所全部終端設備統一管理，也形成了用戶訪問企業內部資源的第一道屏障，只有成功登錄到終端設備，才能查看終端設備中的資源。將 AD域內的所有用戶通過LDAP輕量級目錄服務協議同步至系統用戶信息表中，登錄適配器通過目錄上下文獲取當前終端機器的信息，通過邏輯代碼審核用戶身份，用戶無法訪問設備管理系統資源。所以使用AD域完成系統用戶身份認證作為用戶訪問企業內部資源的第二道屏障。AD域與系統身份認證簡單原理如圖 4-13所示。域認證的過程如下：

（1）在Windows Server 2003服務器中安裝DNS服務器，搭建AD域；

（2）將終端機器加入到域林中；

（3）使用LDAP服務將域林中的用戶信息同步到系統用戶組織中；

（4）使用Javax中訪問AD域中當前終端用戶信息的LDAP相關類；

（5）在登錄適配器中驗證當前終端設備信息。

圖4-13 AD域認證原理圖

系統登錄校驗還可由復雜口令、重鑒別、鑒別失敗凍結賬戶輔助實現。密碼長度需要至少6位，包括大寫字母和數字，在啟用三員審計的情況下，設定密碼修改周期，一個月為修改周期，用戶在登錄系統時，后臺會進行檢查，如果超過修改周期仍沒有修改密碼，則強制輸入老口令和新口令進行修改，修改后才能進入系統。重鑒別是指用戶登錄系統后若空閑時間超過設定的用戶在線時間，需要

重新登錄系統，這個策略是為了避免用戶登錄系統后，臨時離開工位而忘記退出系統，惡意用戶竊取系統數據信息。用戶在線時間是指用戶在該時間間隔內向服務器至少發起一次請求，認為該用戶是處于在線狀態的。在線時間默認為500000 毫秒。鑒別識別凍結賬戶是指用戶在使用賬戶密碼登錄系統時多次登陸失敗，在超過設定的閾值后，該賬戶就會被凍結，暫時不允許登錄系統，需要等待超過凍結時間后才能登錄，凍結時間為10分鐘，登錄次數的閾值設置為10次。

系統登錄認證過程如圖4-14所示。

USB key

經端計籌機

打•開也対覽器

是否在臂

惠與系統數據西雖戶匹配

圖4-14系統身份認證流程圖

4.5.2身份認證機制實現

身份認證主要使用登錄適配器實現AD域認證，在實現身份認證時，需要使用JNDI提供的類，通過獲取當前終端機器的用戶名和密碼，將這些信息與AD 域服務器的賬戶名冊匹配，捕獲異常。Java中可以通過 javax.naming.directory.DirContext 和 javax.naming.directory.InitialDirContext 類訪問AD域中的用戶信息資源，實現系統用戶身份認證。只有在不出現異常的情況下，才能正常登錄系統，后端偽碼如下所示。

if（驗證域信息通過）{

if（若該用戶不在系統賬戶中或被凍結）{

…•…〃提示錯誤信息

..••••• 〃重新登陸

〃登錄成功

}

else if{賬號密碼校驗通過）{

〃登錄成功

}else{

〃口令錯誤或賬戶被凍結

}

4.6安全機制-訪問控制機制

4.6.1訪問控制設計

在4.2小節中己介紹了該部分內容的核心設計與實現。除此之外，還包括對網頁源碼、內容禁止復制、打印操作的控制，方案設計圖如圖4-15所示。這些訪問控制操作可以避免網頁上的數據信息通過源碼的方式被竊取。另外還通過防盜鏈技術對跨過權限的操作進行控制，通過分析網頁是由哪一地址跳轉過來的，來判斷是否是直接在URL中粘貼網頁地址獲取網頁信息。防盜鏈方案設計如圖 4-16o

圖4T6防盜鏈方案設計圖

4.6.2訪問控制實現

在4.2設計章節中介紹了多種粒度組合的策略，從多用戶到單個用戶、從多資源到單一資源，多種粒度策略的實現都是基于組織權限模塊實現的。

在實現角色訪問控制時需要在創建流程模型時制定該節點的參與人選擇規則，需要選擇指定角色尋找辦理人的方案，并指定有哪一角色辦理。在流程執行時會根據路由規則查找角色相對應對的用戶。后臺程序通過實現 ParticipantRoutelnterfkce接口，獲取節點參與者。接口中的方法和參數列表如下表 4-13> 4-14 所示。

表 4-13 Pa r t i c i pa nt Rout e I nt e r face 接口方法

接口方法 I說明

getDescriptionO -獲取當前路由方案的簡單描述說明

routeUserO 獲取當前節點參與者賬戶

表 4-14 Part i c i pantRoute I nterface 參數

參數說明

userContext 當前操作者上下文

processInstanceModel 流程實例屬性

departmentModel 當前操作者部門屬性

departmentID 當前操作者部門ID

workFlowStepModel 當前流程節點模型屬性

workFlowStepID 當前流程節點ID

基于用戶組的訪問控制主要基于多用戶授權方式，在流程節點參與人方案選擇時，選擇指定部門人員辦理，然后還需要選定具體部門。在流程執行到該節點的上一節點時，會根據下一節點的路由規則，將指定參數傳遞到后臺，后臺程序根據路由規則及參數值將目標辦理人返回到前端，用戶就可以選擇下一節點的辦理人了。該方式的實現與RBAC方式一致，需要實現ParticipantRoutelnterface 參數來完成。

基于用戶的訪問控制方式是通過校驗用戶的IP是否為管理員設置的指定IP 地址來判斷用戶是否為合法用戶。該訪問控制主要通過登錄適配器的后臺代碼來實現，實現內容已在第三章介紹過，這里不再介紹。通過創建“由流程創建者辦理"的路由規則，在流程執行到倒數第二個節點時，會在當前流程實例的節點表中查看第一節點的辦理人，并將目標辦理人返回給前端，倒數第二個節點的用戶就可以看到下一節點的辦理人并將任務推送到下一節點中。實現方式類似于基于上述基于角色的路由規則的實現。

網頁訪問權限控制及防盜鏈方案的實現都是采用JS代碼實現的。網頁訪問控制使用了 JS 中的 document.oncontectmenuN document.onselectstart 和 document.oncopy事件。防盜鏈的實現使用了 document.referer來獲取referer的值, 進而判斷上一鏈接地址。

4.7安全機制-安全審計及監控機制

4.7.1安全審計及監控機制設計

1.安全審計

一般的信息系統都存在一個管理員，由于管理員權限較大，對系統安全存在威脅。為了限制管理員的權限過大，提出三員審計策略。應用三員管理的目的是實現三員權限隔離、相互制約的監督關系，避免超級管理員的存在。這也是我國信息系統安全保護規定中要求的不能設置超級管理員的角色。

系統管理員主要負責應用系統的建模配置、運行管理及非安全參數調整等工作，實施和配置業務流程系統，査看與系統異常相關的日志。安全保密員主要負責系統賬戶的創建、權限的分配、系統內安全事件的審查處理、審査安全審計員的操作行為【河。安全保密員負責制定和實施平臺組織結構、角色及設定權限安全策略、導出并分析用戶相關操作日志。安全審計員主要審查系統管理員和安全保密員的行為，對可以的信息進行安全審計和跟蹤監控，同時也審查普通用戶的安全行為。三員審計的具體內容如圖4-17所示。

ccnscle.lag

error.log

入站隼成

出站集成

舷管理竝作日志一噸

1管理操作

越權訪問警告系統告善日志二

- 賬戶:東結記錄

圖4-17三員審計關系圖

2•系統監控

BPM平臺為企業網絡管理人員和高級系統管理員提供了監控CPU、內存利用率等信息的接口，根據系統性能監控需求，實現對CPU及內存等利用率的監控。通過查看這些監控指標，可以提前發現或預防某些潛在危險情況，提高系統的穩定性和健壯性。

4.7.2安全審計及監控機制實現

1 •安全審計

安全審計由三員權限控制、系統操作記錄審計組成。通過開啟并配置BPM 平臺三員權限，可以實現三權隔離、相互制約的監督關系。三員權限說明已在設計模塊描述，在日志審計方面，啟用三員后，只允許系統管理員查詢、分析日志記錄：只允許安全保密員查詢、導出與用戶安全操作有關的數據，同時可以查看 “安全審計員”操作日志；只允許安全審計員查詢、導出與其他管理員有關的操作日志，不允許調查自己的行為日志。對于審計日志，使用AuditAPI類中的 logUnauthorizedAccess、logAdminOp、logClientOp 等方法來實現。

logUnauthorizedAccess方法用于實現對功能模塊的越權訪問進行審計。越權訪問審計，通過指定source和ip生成對應功能模塊的越權訪問日志。參數列表如下表4-15所示。

表 4T5 方法 IogUnauthor izedAccess 參數列表

［參數說明

[String auditObj 審計對象、越權訪問的功能模塊 ;

! String title 日志標題 I

String source 審計事件的來源

String ip 操作人或系統端的IP I

I Map trace 詳細描述 I

logAdminOp方法用于生成管理操作日志。該方法的參數列表如下表4-16所示。記錄管理員操作類型日志時可使用以下語句實現。

AuditAPI.logAdminOp（CataIog.MODEL,”設備管理”，”新增”,”新增設備采購流程組",trace,LeveLINF O）;

表4-16方法I ogAdm i nOp參數列表

1參數說明

Catalog catalog 操作類型編碼

String auditObj 審計對象，表單模型等

String action 操作關鍵字，更新、新增

! Steing title 日志標題

i Map trace 詳細描述

Level level 日志級別，INFO、DEBUG、WARN、

ERROR

logClientOp方法用于生成客戶操作日志。該方法的參數列表與logAdminOp

方法一致，不再描述。

2係統監控

BPM平臺提供了監控CPU資源、監控內存資源、監控數據庫連接池、監控在線壓力及并發壓力及監控操作系統進程的可視化工具及擴展接口。API接口中提供了性能監控事件接口 PerformanceAlarmlnterfece接口，開發人員可以通過實現該接口完成性能監控擴展。目前已經實現了對服務器CPU和內存使用情況的監控、在線用戶數量的監控，通過系統監控能夠更好地評價系統的穩定性和健壯性。

4.8本章小結

本章主要介紹AES優化算法，AES算法的加解密時間和可靠性是其重要屬性，航天設備信息管理系統對數據加工的速度和安全性都有要求，但由于航天企業屬于保密性企業，系統運行環境具有天然的保護屏障，算法的安全性滿足了系統需求，所以本人對AES算法的加密過程進行優化，從而提高了算法的加密速度。算法的優化結果是明顯的，其安全性在理論上是沒有受到影響的，但實際安全性需要經過大量的攻擊模擬行為來確定。所以，在展望工作中會把優化后的 AES算法的安全性作為研究內容之一，深入剖析安全性。然后，還介紹了基于多粒度組合的訪問控制策略的研究過程，該策略是針對設備系統多粒度授權的特定設計的,其靈活授權的優勢大于管理不便的劣勢;最后介紹了安全機制的設計、實現過程。安全機制的選擇需要考慮了系統實際運行環境及研究所已具備的安全防范措施。

第五章系統測試及結果分析

軟件測試并不是驗證程序的正確性，而是去查找程序中的錯誤。為了做好軟件測試，必須遵從以下幾點原則：

(1)軟件測試工作貫穿整個軟件項目生命周期【351。

(2)某一模塊或功能的測試工作盡量避免由負責該模塊的開發人員來做。

(3)測試工作要保證規范化。

(4)發現錯誤及時反饋。

為了提高軟件測試的質量，小組開發人員采用交叉測試方式，遵守以上測試原則，在發現BUG后及時進行了修復，并在修復完成后交付測試人員進行回歸測試。目前，系統己部署在航天所服務器上，運行狀態正常。

5.1系統運行環境

在實現章節介紹了開發環境，航天研究所提供的設備系統服務器硬件配置為酷睿四核i5、8GDDR3、500G SAIA,企業規模屬于中等企業，以上服務器配置滿足系統運行的需求，若后期并發訪問量較大，可以對服務器擴容，均衡服務器訪問壓力。系統訪問在內網中，外網無法訪問，內網環境的水平滿足服務器與客戶端機器之間的帶寬要求。系統測試環境和運行環境均為IE8瀏覽器。

5.2系統功能測試

系統功能包括基于流程、報表、用戶視圖的三類模塊。由于系統功能模塊較多，若在測試章節中全部一一列出篇幅會太長，所以本章摘選了基于流程的一個代表模塊做測試工作的論述。基于工作流的模塊需要著重測試流程實例的節點辦理、流程跳轉規則及數據傳遞一致性問題等a】。

基于流程的功能模塊的測試方法論述以供應商新增申請流程為例，按照軟件測試的流程，供應商新增流程測試步驟如下。

一、確認需求和設計文檔的說明

該內容在需求章節和設計章節中都已論述。該模塊流程模型如圖5-1所示。

二、測試用例的設計

該流程主要包含三個節點，每個節點辦理角色不同，且節點內容也不同，所以需要根據實際情況對三個節點分別設計測試用例。下面詳細介紹各個節點的測試用例。

（1）普通用戶通過菜單入口發起供應商新增流程，該節點主要實現啟動供應商新增申請的流程。該節點測試的前提是普通用戶己成功登錄系統。

表5-1供應商新增測試用例

編號輸入期望結果

| 1 點擊“供應商管理流程組” 出現新建界面

2 不點擊“供應商管理流程組” 不出現新建界面

3 點擊“新建” 流程啟動

4 不點擊“新建” 流程不啟動

（2）節點一測試用例，該節點主要審批由節點一提交的申請信息，在審批頁面中包括供應商基本信息、審批菜單等。該節點測試的前提是部門領導已成功登錄系統。

表5-2節點一測試用例

編號輸入期望結果

1 不填表單，點“提交” 提醒必填項缺少信息

2 缺少必填內容，點“提交” 提醒必填項缺少信息

3 必填項完整，點“提交” 提交成功，選擇下一節點辦理人

4 基于用例4,不選審批人流程不跳轉至下一節點

5 基于用例4,選擇審批人流程跳轉至下一節點

（3）節點二測試用例，該節點類似于第二個節點的測試，不同之處是該節

點不能編輯表單信息，只能選擇審核菜單。

表5-3節點二測試用例

編號輸入期望結果

1 不選審核結果，點“提交” 提示沒有選擇審核結果

2 評審選擇“同意”，點“提交” 彈出選擇下一節點辦理人的窗口 1

3 評審選擇“不同意”，點“提交” 提示沒有填寫審批意見

4 基于用例2,不選審批人流程不跳轉至下一節點

5 基于用例2,選擇審批人流程跳轉至下一節點

6 基于用例3,填寫審批建議并選擇審批人流程跳轉至第一節點

7 基于用例2,不選審批人流程不跳轉至下一節點

（4）節點三測試用例，該節點為供應商新增流程的最后一個節點，同樣具有審核菜單，如果審核通過，則流程辦理結束；否則，需跳轉到第一節點由申請人修改完善申請信息。

表5-4節點三測試用例

編號輸入期望結果

1 :不選審核結果，點“提交” .提示沒有選擇審核結果

2 評審意見為“同意”，點“提交” 提交成功，流程辦理結束

3 評審意見為“不同意”，點“提交” 提示沒有填寫審批建議

4 基于用例3,填寫審批建議并選擇審批人 :流程跳轉至第一節點

三、測試步驟

:L點擊“供應商管理流程組”菜單，出現新建申請流程實例界面。

食越樣帶” ：；:：w . .. •

發岀韻朗說ES

35?

;.：：.®z£=^£i；=e3!

.;:::；»Sg?=a 注 S；

圖5-2點擊“供應商管理流程組”出現“新建”按鈕

2.點擊噺建"按鈕，流程啟動。

3.節點一測試。

（1）填寫申請表單信息，若必填項未填寫完整，則在提交時不會通過表單

數據校驗，用戶必須填寫完整才能提交。

■ ' ?f j : :

| 5'4 :| S y

圖5-4必填項填寫不完整，提示信息

（2）表單信息填寫完整，則允許提交。為了測試方便，這里均采用管理員作為審批人員。

-..;.-.■ ■. -曲

M據衍畫口 X

•- . : -.■：•, . ；；：.:：5'.咎 ”:了

■ '•■ :

己習傳自訓左45扶'血•技融手三蛀給卜蒯

辦逢人：

d務杯罡： i滋門氮旦魚姬i立克旨歸程:超門上謝朋F

優先級：廉無is 中■-' ■£

圖5-5必填項填寫完整，提交成功

4.節點二測試。

(1)節點二辦理者發現有新的待辦通知。

BPM Solution LOGO 言輕 » I 卄舲

Fwe®« scn^

3、酋頁

=一.當用

—伽工作白

.：.!.j卿1、寓齟戸:發??的待辦任務-郃•用暮同WFSW理殛巒

m珈用m

m < i5&tx3ES

w ...；雨期師

=”笑 Ff

.；：匿淀資=啟用申iS s固走貯祗第存申済

-.持松g巒星

w ..iSfta«：

-WE逹

g系竝護

圖5-6供應商新增審批待辦通知

BPM Solution LOGO

Prices* ng：

圖5-8審批表單及節點辦理信息

（3）不選擇審核結果，直接提交，則提示用戶選擇審核結果。

圖5-9提示用戶填寫審核菜單

（4）若選擇“同意”,則提交時出現選擇下一節點辦理人的對話框。選擇下一節點辦理人，則流程成功跳轉至第三節點，由下圖5-10可知下一辦理節點名稱為“設備儀器主管審批”。

我田工作臺審共&商它陛$程部門1翔試用戶“

圖5-10選擇下一節點辦理人

（5）若選擇“不同意”，且不填寫意見，提交時則提示用戶填寫審核建議。

圖5-11未填寫審核意見時的提示信息

（6）若審核菜單選擇“不同意”，并填寫審核意見，則流程跳轉至第一節點，由申請人重新提出申請。由下圖中，可以發現下一辦理節點名稱為“填寫供應商數據”。

八音頁「芒叢的工作臺*

儲注作臺；魯訂領尊車就濮應商它理注程甸儘戶\

跌乳行窗口

I - .. :- - ■::

辦理人：aws-test 戶 >

可送范國： admin苗里員〉

-—~~T~一~ 任勞徐冬捆虧陸冃數翩逅帝管理W軽箭耳畫

優先級：&無鬲中低

、'謚必聲娶燙紓鏡務護：弊

> （-'• ' - ■ > -；；• ' f ' - :=■—：；•、：：• 一：--•：•

圖5-12審批未通過時流程跳轉至第一節點

5.節點三測試。

（1）節點二辦理者發現有新的待辦通知。與節點二辦理者登錄后的情況類似，這里不再粘貼截圖。

（2）不選擇審核菜單，直接點擊“提交”，則提示用戶選擇審核菜單，與節點二相同情況下的提示信息一致。

（3）在選擇“不同意”時，提交信息則提示用戶填寫審核意見，與節點二相同情況下的提示信息一致。

（4）若審核菜單選擇“不同意”，并填寫審核意見，則流程跳轉至第一節點，由申請人重新提出申請。。

（5）選擇“同意”并提交，則流程結束，并給該流程發起人發送消息，提醒流程已結束，如下圖5-13、5-14所示。

'來目網頁的消息 1

:；* 您有Y［管理員］發來的待辦E務-［通知:濮完畢］供應商管理漏呈-部

門1-管理員確定

圖5-13流程結束通知（1）

BPM Solution LOGO

丹X*経興沁

圖5-14流程結束通知（2）

（6）流程實例執行路徑如下圖5-15所示。

（7）通過查詢供應商名冊，通過申請流程新增的供應撒很難過已存在于名冊中，如圖5-16所示。

四、測試結論

按照上述流程測試方法，還完成了設備采購申請流程、設備驗收入賬申請流程、設備直接入賬申請流程、其他資產入賬申請流程及設備領用申請流程。不同的流程需要流程實際需求設計特殊的測試用例，不過流程測試的核心就是將流程所有路徑分支都要覆蓋到，保證流程順利執行。

5.3系統安全機制測試

安全機制并不是系統功能模塊，而是在實現系統功能時附加的安全措施。測試安全機制時，需要基于功能模塊完成測試。測試系統安全機制時需要注意判斷安全性達標的標準，切實考慮實際應用場景［37】。本小結主要介紹訪問安全體系中系統安全防護機制的內容。

1.密級標識測試

密級標識是用于標識實體密級的，包括人員密級、表單密級和流程密級。人員密級作用于業務邏輯控制，沒有展示的界面,這里僅展示表單密級和流程密級。表單密級通過供應商管理模塊測試，如圖5-17；流程密級通過設備領用申請模塊測試，如圖5-18o

yvce辺3.対£2肚3扣0"炳;;•《£；：諾”;嚴＞.曲趣匕

圖5-17表單密級

圖5-18流程密級

2•身份鑒別測試

身份鑒別主要實現研究所內已入域的用戶免登錄系統，所以系統的身份鑒別是基于終端機器的賬戶登錄身份鑒別機制的，打開系統登陸頁面后，頁面會自動獲取當前終端機器在域中的賬號信息，并將獲取的信息與系統中的賬號信息進行對比，對比通過則自動登錄成功，否則登陸失敗。自動登錄的實現避免了用戶對登陸信息的干預，普通惡意用戶即使獲取了系統中合法的用戶名和密碼，也無法進入系統訪問資源。另外，身份鑒別還包括重鑒別、凍結賬戶、空閑時間超時重登錄等機制。下面展示各個身份鑒別機制測試結果。

(1)自動登錄。使用在域中的終端機器，打開IE瀏覽器，在URL地址欄中輸入系統訪問地址，可自動登錄；使用不在域中的終端機器，打開IE瀏覽器，在URL地址欄中輸入系統訪問地址，自動登錄失敗。圖5-19是自動登錄的過程截圖。

. £

® - -

•，遂;r沁義”夠 :-.. 于-m- s-i.. - -幺“

AIUJS BPM

圖5-19自動登錄

(2)用戶登錄后，空閑(無請求)時間超過500000ms后，被退出，下次請求時重新登錄。測試該用例的前提是用戶已登錄到系統中，在不操作系統的情況

下計時，測試當時間小于500000ms,等于500000ms和大于500000ms時系統資源是否能被訪問。測試發現當空閑時間小于或等于500000ms時，系統資源能被

訪問；大于500000ms時，系統資源不能被訪問，需要重新登錄系統。

圖5-20重鑒別

(3)多次登錄失敗，賬號凍結。測試該用例時，需要注意臨界條件，選取登錄失敗次數分別為8次、9次、10次和11次。測試結果為失敗八次后，再次用正確的終端賬號登錄系統可以登錄成功；失敗九次后，再次用正確的終端賬號登錄系統可以登錄成功；失敗十次或失敗十一次后，再次用正確的終端賬號登錄系統時，提示用戶被凍結，需要聯系管理員。測試結果證實該身份鑒別機制測試通過。

A-<>1 A & » ?. xgisae- J； < anry ' F：了二二養 F-w* “ 二廠” ” 慘^躍秤' J > 攻為：g

O • U 10 ：K,.- ：；4 J - “亠秦， a ~

,.i竣瞬，疋

j 3F” Mesiase \ •匚• • w • rix---空金玄、切

f > 二三用

: - 桶癬怒滋§ 〔…玄.

“二軌二 ,^®ae “-mom t~ ;,“^wdr_ .. .mwriiT； i . iwimm皿

3.訪問控制測試

訪問控制的設計與實現在前面章節已經敘述過了，這里展示在功能模塊中時如何應用訪問控制機制的。

（1）基于角色的訪問控制

基于角色的訪問控制主要作用于節點辦理授權，每個審核節點的辦理角色不同，能訪問到的表單信息也不同。如圖5-22所示，下一辦理節點名稱為設備主管人員審批，則提供的可選辦理人名單中包括了角色為設備儀器主管的人員，且人員密級不能小于當前流程密級，否則將無法參與到流程中來。

ww san■:ir.«: - 趺三:、 - acrr：r：<W$5 >

圖5-22基于角色和密級的訪問控制

（2）基于用戶的訪問控制

為了方便測試，測試前將aws-test用戶的登錄IP指定為10.108.37.103, aws-test使用10.108.37.102的機器登錄時，禁止登錄。若將該用戶的登錄IP指定為10.108.37.102,則登錄成功。如圖5-23所示，若終端設備的IP與指定用戶對應的IP地址不一致，就會出現請求執行失敗的提示。基于用戶的訪問控制，將訪問權限授予某一具體的用戶，其授權粒度較小，能夠實現靈活授權。

在圖5-24中的系統操作日志中可以發現用戶嘗試使用10.108.37.102機器訪問系統的記錄。

10.108.39.82:8080 盡示:

[N a v i gatia n_F ra m e_B otto m]

Request *ails, try re-run!

圖5-23基于用戶的訪問控制

二 S¥S_AUDIT_l-OG

圖5-24基于用戶的訪問控制

（3）基于用戶組的訪問控制

基于用戶組的訪問控制使用設備領用流程測試，設備領用申請部門的人員只

能領用本部門的設備資源。

圖5-25基于用戶組的訪問控制

（4）基于任務的訪問控制

基于任務的訪問控制使用領用流程來測試，設備領用申請流程最后一個節點的辦理任務需由流程發起人來辦理，以便申請人對領用到的設備進行確認。

〈滾備烷需主訓族jiS備轅月甲誨懿-SB門1 -齟吳

圖5-26基于任務的訪問控制

（5）基于密級的訪問控制

圖5-27用戶不能訪問高于本身密級的表單數據

圖5-28用戶可以訪問不高于本身密級的表單數據

八\ 近不起，冃尸【澆試后戶）無處淫【秘總:，密】級別的權限，任勢不能^圏

圖5-29用戶不能執行高于本身密級的流程

(6)

禁止復制網頁信息及防盜鏈。

購置申請單

曰謹塢號：GZ320170245

V諳迭擇要遴行的按作：辱屁意•不同意飯蚩言估0販字內聲

圖5-30對頁面源信息的訪問控制

圖5-31防盜鏈

4.系統日志審計

系統日志審計主要是通過設置三員權限，提高系統操作行為的監控及預防。為了方便管理，對系統客戶端操作、管理端操作及安全日志進行了統計分析，并對告警級別作出餅狀圖，便于管理員對各類行為占比的分析，進而提高系統安全

防范意識。

圖5-33系統三類審計級別占比

（普通:I eve 10,警告:I eve 11,錯誤：level 2）

5.4系統性能測試

自系統部署到航天所服務器上后，系統運行趨于穩定，沒有性能故障。系統性能測試主要是針對用戶在并發訪問時，服務器能否正常提供系統服務，且保證響應時間在用戶能夠接受的正常范圍內。本系統已部署在研究所服務器上，根據上線之后的記錄與反饋，并發訪問時，系統保持流暢運行，滿足研究所對于系統穩定性與流暢性的要求。性能測試過程如下：

（1） 100人并發訪問測試

100人在同一時間登錄到系統并進行日常工作，完成流程的啟動、流轉、撤回及辦理等操作，測試結果為流程啟動等工作的平均響應時間為1.302秒，系統運行正常，未有異常。

（2） 200人并發訪問測試

200人在同一時間登錄到系統并進行日常工作，完成流程的啟動、流轉、撤回及辦理等操作，測試結果為流程啟動等工作的平均響應時間為1.825秒，系統運行正常，未有異常。

（3） 500人并發訪問測試

500人在同一時間登錄到系統并進行日常工作，完成流程的啟動、流轉、撤回及辦理等操作，測試結果為流程啟動等工作的平均響應時間為2. 561秒，系統運行正常，未有異常。

以上性能測試結果表明系統能夠穩定運行在企業內部，為企業設備管理提供服務。性能測試還包括前端頁面的渲染速度、服務器CPU及內存的消耗程度，各項指標均顯示正常，用戶體驗良好。

5.5本章小結

本章主要論述了系統功能模塊的測試內容。系統的好壞需用戶使用之后來評定，系統投入運行后，運行正常且處于穩定狀態，能夠滿足航天所設備管理日常需求，用戶反饋良好。后期工作包括對一些功能進行優化和拓展，還包括安全機制的加固和升級。

第六章總結與展望

6.1工作總結

本文基于BPM建設了一套符合航天研究所業務需求及安全需求的航天設備信息管理系統，目的是完成研究所設備管理方式轉型，實現設備信息化管理，提高設備管理效率。下面對主要工作內容進行總結。

首先，論文論述了航天設備管理系統安全機制的功能性需求和非功能性需求，所有需求性結論都是基于航天研究所設備管理調研結果。除此之外，本人還閱讀了大量的文獻，調研出設備信息管理系統的研究現狀、建設現狀以及技術現狀，完成了系統建設的技術選型工作。在技術介紹小節中，不僅介紹了適合航天設備信息管理系統建設的通用性技術,還論述了為什么要選擇該通用技術來開發系統。

其次，論文論述了設備系統的功能設計與實現過程。由于設計工作是基于研究所原有業務的，在把人工業務工作轉換為系統模塊時，花費了較多時間來完成信息化模型建設工作，最終撰寫了設計文檔，便于系統的擴展與維護。系統的實現工作主要是論述各個功能模塊是如何實現的，通過類圖、時序圖的方式清晰地描述了實現過程。

然后，論文論述了安全機制的設計與實現。由于航天研究所屬于軍民融合的涉密性企業，員工日常業務工作中會有敏感信息的存在，為了保護敏感信息不被惡意用戶泄露等，安全機制的建設是非常必要的。本人通過調研大量的信息安全文獻，總結出了信息管理系統安全技術體系架構，覆蓋人、物、軟硬件等多元素的安全管理措施。最后，在結合航天研究所現有安全環境和系統運行環境的條件下，設計并實現了符合研究所安全性需求的安全機制。

截止到今天，系統運行正常，且沒有發現嚴重級系統故障，也沒有安全事件發生。航天所設備管理完成信息化建設工作。

6.2工作展望

航天研究所設備信息化建設工作已經完成，但隨著航天所設備管理業務的擴展，管理系統可能需要功能的擴展或者安全機制的改善。展望工作包括但不限于以下幾個方向的內容。

首先，航天設備信息管理系統實現了當前業務功能的線上管理，但隨著業務的增加，未來需要對系統功能模塊進行擴展，所以接下來會對系統代碼進行優化維護，提高代碼質量，做好代碼版本控制工作。當研究所有新的需求時，能夠在現有代碼的基礎上盡快實現需求，最好能做到熱部署。

其次，持續關注系統各方面性能，包括系統穩定性、系統反應時間及系統易用性。雖然現在用戶量不是特別大，但需要保證系統在未來用戶量較大時，甚至是在高并發訪問時，能夠承受住壓力，保證數據安全。所以，接下來會進行系統性能優化的工作，包括并發訪問瓶頸的測試、數據庫讀寫性能瓶頸的測試、服務器擴容及容災工作。另外，還可建設實時監控系統，將設備信息管理系統接入監控系統，提供實時監控的服務，并將系統運行情況生成日志，以便運維人員進行系統維護。

最后，為了防御未來的一些攻擊行為，后期也會把工作重點放在安全機制的改進上。系統目前處于安全的狀態，但不代表未來不會遭受到強攻擊，所以，對于系統安全要保持防范于未然的態度，做好安全建設工作。在安全訪問控制方面，有學者提出了基于屬性的安全訪問控制盟，在多粒度訪問控制的策略中，可以探索較好地組合方式，提高管理效率及授權效率。從宏觀角度來看，信息系統安全機制的建設工作具有非常重要的意義，未來會繼續跟進該類系統在安全領域的技術革新，切實做好安全防范工作。

參考文獻

[1]余維，羅愛靜.企業MIS理論與發展對策初探卩].科技情報開發與經濟，2007, (29): 147-149.

[2]柳賽男.基于Web的制造業倉庫管理物流平臺關鍵技術及其應用研究 [D].浙江：浙江大學，2007.

[3]曹開彬，邳佳琦.透過“棱鏡”看國產IT產品的可替代性[J].軟件產業與工程，2013(05):10-14.

[4]李迎濤，馬春光，李增鵬.涉密信息系統互聯互通關鍵技術研究[J]. 信息網絡安全，2013, (08):25-30.

[5]陳金仕，王軍元.國有企業涉密信息系統分級保護探討與體會[J].中國西部科技，2011, 10(20):55-56+65.

[6]尹開賢.軍工單位信息系統的安全保密形勢與對策[A].現代通信國家重點實驗室、《信息安全與通信保密》雜志社.//第十一屆保密通信與信息安全現狀研討會論文集[C],現代通信國家重點實驗室：《信息安全與通信保密》雜志社，四川信息安全與通信保密雜志社，2009: 4.

[7]高峰.支持移動業務的企業流程管理系統的設計與實現[D].上海：復旦大學，2011.

[8]顏超.以數據為中心業務流程模型的訪問控制技術研究[D].上海：東華大學，2012.

[9]崔碩.工作流模型結構驗證及運行仿真的研究與實現[叨.北京：華北電力大學，2012.

[10]李慧霞.基于J2EE和MVC設計模式的Web應用研究與實現[D].陜西：西安電子科技大學，2006.

[11]常敬玉.基于屬性的訪問控制在多域網絡中的應用[D].陜西：西安電子科技大學，2012.

[12]劉善軍.基于本體的訪問控制模型研究[D].陜西：西安電子科技大學, 2013. DOI:10.7666/d.D365161.

[13]張劍，董曉明.一種基于行為的B/S應用系統訪問控制策略[J].計算機與數字工程，2016, 44(01):106-108+147.

[14]胡鵬.基于UCON的工作流管理系統訪問控制的研究與實現[D].上海: 上海海事大學，2007.

[15]初曉璇.數據加密技術在安全電子交易協議中的應用[C]. //第六屆中

國管理科學與工程論壇論文集.2008:718-723.

[16]高明.淺談對稱加密算法與非對稱加密算法的應用[J].電子世界， 2015(15):59-60.

[17]吳濱.密級標識技術在分級保護中的應用[JJ.信息安全與技術， 2010(06):76-79.

[18]蘇賓，成立權.企業信息安全標準體系建設的初步探討[J].計算機光盤軟件與應用，2012, 15(21):40-41.

[19]黃梁標，郭正華.涉密應用系統三員分離設計與研發[J].計算機光盤軟件與應用，2013, 16(01):10-12.

[20]彭嬌，聶慧.淺析關系型數據庫設計的理論和實踐[J].科技創新導報， 2014, 11(20):54.

[21]李英甫.基于使用控制模型的文件安全管理研究[D].北京：北京交通大學，2012.

[22]賈旭.AES算法的安全性分析及其優化改進[D].吉林：吉林大學， 2010.

[23]朱松柏，肖順文，江敏.基于FPGA的AES解密算法研究[J].成都工業學院學報，2016, 19(02):27-30.

[24]張堯，葉玲.基于AES的WSN加密算法[J].計算機工程與設計，2015, (3):619-623. DOI:10.16208/j. issnl000-7024. 2015. 03. 012.

[2習周志烽，王晶.基于RBAC的安全管理模塊的設計與實現[J].電信工程技術與標準化，2010, 23(10):84-88.

[26]張曉群，董麗麗.角色訪問控制模型的研究及應用[；]•計算機技術與發展，2007, 17(2):42-45.DOI:10.3969/j.issn.l673-629X.2007.02.012.

[27]Anil L. Pereira, Vineela Muppavarapu, Soon M. Chung. Managing Role-Based Access Control Policies for Grid Databases in OGSA-DAI Using CAS [J]. Journal of Grid Computing, 2007, 51:.

[28]孫軍紅，李娟.一種基于任務和角色的工作流訪問控制模型[J].計算機工程與應用，200& 44(30):21-23.DOI:10.3778/j.issn.l002-8331.2008.30.006.

[2刃張文藝，工作流程管理系統的訪問控制研究與實現[D],江蘇：南京航空航天大學，2004

[30]于春生，聶晶.基于組和角色的工作流權限訪問控制模型[J].計算機應用，2011, 31(03):778-780+783.

[31 ] Headayetullah M, Pradhan G K. Efficient and Secure Information Sharing For Security Persomels: A Role and Cooperation Based Approach[JJ.

International Journal on Computer Science and Engineering? 2010, 2(03).

[32]Guowei Wang, Guangming Xu, Manjun Xue. Unified Identity

Authentication between Heterogeneous Systems Based on LDAP and RBAC[J]. Journal of Networks, 2014,910:.

[33]麻小軍.基于LDAP的單點登錄系統的研究與實現[D]?遼寧省：東北大學，2010.

[34]楊曉華.航天科技集團物資跨院協同管理系統設計與實現[D].北京：北京郵電大學，2012.

[35]李曉巖.軟件測試的應用與探析[J].讀寫算(教育教學研究)，2014, (11):130-130.

[36]Shengli Wu, Amit Sheth, John Miller, Zongwei Luo. Authorization and Access Control of Application Data in Workflow Systems[J]. Journal of Intelligent Information Systems, 2002, 181

[37]黨政，楊同慶.涉密信息系統安全技術探究[J]?技術與創新管理，2014, 35(2):128-131.DOI:10.3969/j.issn.l672-7312.2014.02.011.

[3 8] Torsten Priebe, Wolfgang Dobmeier, Christian Schlager, Nora Kamprath. Supporting Attribute-based Access Control in Authorization and Authentication Infrastructures with Ontologies[J]. Journal of Software, 2007, 21 ：?

【本文地址：http://www.bzhlmm.com//guanlilei/gongshangguanli/xixinguanli/8982.html】

上一篇：基于 BIM 的城市綜合管廊設施信息管理研究

下一篇：沒有了

相關標簽:

最熱期刊