關(guān)亞東，許磊，李中偉，朱識天，譚凱，王艷敏

(1. 哈爾濱工業(yè)大學(xué) 計算機(jī)科學(xué)與技術(shù)學(xué)院，哈爾濱 150001；2.哈爾濱工業(yè)大學(xué) 電氣工程及自動化學(xué)院，哈爾濱 150001)

0 引 言

繼電保護(hù)是電網(wǎng)安全運行的根本保證，繼電保護(hù)裝置及時切除故障是避免事故范圍擴(kuò)大、保證電力設(shè)備安全運行的重要手段。定值是繼電保護(hù)裝置進(jìn)行邏輯判斷時的重要參數(shù)之一，其準(zhǔn)確性決定了繼電保護(hù)裝置動作的正確性。傳統(tǒng)的繼電保護(hù)定值管理與發(fā)放模式為在電力調(diào)度中心進(jìn)行整定計算得到電力系統(tǒng)保護(hù)裝置定值后生成定值單，并進(jìn)行定值單的人工審核和審批，而后通過人工下發(fā)到各變電站，進(jìn)而完成現(xiàn)場定值核對與執(zhí)行工作。這種依靠人工操作的定值單管理下發(fā)模式無法實現(xiàn)定值單在各部門之間的自動高效流轉(zhuǎn)，極大地浪費了人力、物力；而且存在大量的重復(fù)工作，導(dǎo)致在日常管理中定值單的匯總、查詢極為困難，甚至出現(xiàn)由于人為原因?qū)е露ㄖ祮蝸G失及兩份定值單不一致等情況，對定值單流轉(zhuǎn)過程也缺乏有效監(jiān)管。

隨著電力系統(tǒng)信息化與智能電網(wǎng)的發(fā)展，有不少學(xué)者研究利用信息化方法以提高繼電保護(hù)的定值發(fā)放管理效率。文獻(xiàn)[1]給出了繼電保護(hù)定值在線發(fā)放管理的總體方案，并設(shè)計了一種通過電力系統(tǒng)通信網(wǎng)提高繼電保護(hù)工作效率的具體方法。文獻(xiàn)[2-3]提出了一種基于分布式多自主體網(wǎng)絡(luò)下的繼電保護(hù)定值發(fā)放管理方案。繼電保護(hù)定值的在線發(fā)放與管理提高了定值單流轉(zhuǎn)效率，減少了繼電保護(hù)工作人員的工作量[4]。但與此同時，繼電保護(hù)定值的在線發(fā)放與信息化管理也帶來了信息安全問題。近年來， 通過通信網(wǎng)絡(luò)攻擊電力系統(tǒng)，破壞電力數(shù)據(jù)的事件時有發(fā)生[5]。

針對繼電保護(hù)定值在線發(fā)放的準(zhǔn)確性與安全性這一問題，國內(nèi)外進(jìn)行了廣泛研究。文獻(xiàn)[6-7]在分析電力系統(tǒng)通信網(wǎng)絡(luò)環(huán)境的基礎(chǔ)上，對保護(hù)定值在線發(fā)放管理系統(tǒng)的安全需求以及其面臨的安全威脅進(jìn)行了研究。文獻(xiàn)[8]在分析智能電網(wǎng)中的繼電保護(hù)定值可能面臨的各種信息安全威脅的基礎(chǔ)上，給出了相應(yīng)的安全防護(hù)方法，該方法將加密技術(shù)與數(shù)字簽名技術(shù)結(jié)合起來。

文獻(xiàn)[9]研究通過基于角色的訪問控制策略，設(shè)置用戶組與用戶角色以確定用戶訪問定值單數(shù)據(jù)的權(quán)限。同時，為便于管理員進(jìn)行安全審計，系統(tǒng)會將各用戶的操作日志記錄下來。文獻(xiàn)[10]研究設(shè)置防火墻以過濾外部人員非授權(quán)訪問繼電保護(hù)數(shù)據(jù)服務(wù)器的行為。然而，通過對上述文獻(xiàn)分析可知，現(xiàn)有的訪問控制策略僅能夠阻擋外部人員的非授權(quán)訪問；利用數(shù)字簽名可保證數(shù)據(jù)來源的正確性，但定值的實時性無法保證，因此繼電保護(hù)定值也面臨著重放攻擊的威脅；此外，部分系統(tǒng)將加密算法所使用的密鑰也寫入到程序中，密鑰安全性無法得到保證。

為解決某地區(qū)電力調(diào)度中心繼電保護(hù)定值單長期依靠人工發(fā)放工作效率低的問題，在考慮上述安全問題的基礎(chǔ)上，擬設(shè)計具有定值單錄入、定值單在線校核與審批、設(shè)備參數(shù)上傳等功能的繼電保護(hù)定值在線發(fā)放管理系統(tǒng)；基于SSL/TLS協(xié)議構(gòu)建系統(tǒng)安全信道，設(shè)計系統(tǒng)雙因子身份認(rèn)證方案、基于任務(wù)的訪問控制策略和基于安全信道的數(shù)據(jù)加密/解密方案，構(gòu)建完整的系統(tǒng)安全防護(hù)方案。

1 系統(tǒng)需求分析

1.1 功能需求分析

定值單在線發(fā)放流轉(zhuǎn)是定值在線發(fā)放管理系統(tǒng)的基本功能，具體來說，是在與現(xiàn)有各類保護(hù)定值單格式兼容的基礎(chǔ)上，實現(xiàn)定值錄入、定值校核、定值批準(zhǔn)、定值接收、設(shè)備參數(shù)上傳、設(shè)備參數(shù)接收、定值單修改和定值單駁回等功能，并可實時查看、追蹤定值單所處的狀態(tài)。

繼電保護(hù)定值在線發(fā)放管理系統(tǒng)應(yīng)能自動形成日志文件，記錄用戶名稱、登陸時間、操作內(nèi)容、所操作定值單編號、操作時間及其IP地址等信息，監(jiān)測定值單的生成、流轉(zhuǎn)、在線下發(fā)和設(shè)備參數(shù)的填報、上傳、訪問等各個流程，系統(tǒng)需提供日志記錄和查詢功能。保障對定值單和設(shè)備參數(shù)的操作具有可追溯性，同時方便各級用戶根據(jù)需要依據(jù)每個定值單的實時狀態(tài)有針對性地聯(lián)系上游用戶解決問題，更加快捷、便利地完成定值發(fā)放管理工作。

在定值單較多的春檢階段易出現(xiàn)分發(fā)不及時或分發(fā)錯誤等問題，因此，該系統(tǒng)需實現(xiàn)春檢校核、批量打印、批量流轉(zhuǎn)等功能，實現(xiàn)同質(zhì)化的批量處理。同時，為更加高效、簡明、安全地實現(xiàn)用戶的添加、刪除、修改，需建立層次分明的用戶管理機(jī)制。同時為便于記錄的管理，系統(tǒng)需支持?jǐn)?shù)據(jù)庫遠(yuǎn)程備份及日志記錄查詢功能。

1.2 安全需求分析

繼電保護(hù)定值在線發(fā)放管理系統(tǒng)工作于電力調(diào)度專用數(shù)據(jù)網(wǎng)安全區(qū)IV，其通信網(wǎng)絡(luò)在物理上與外部網(wǎng)絡(luò)隔離，因此安全威脅大多來自于局域網(wǎng)內(nèi)部。信息安全威脅可分為截取、篡改、阻斷以及偽造四大類[11]。下面具體結(jié)合繼電保護(hù)定值在線發(fā)放管理系統(tǒng)進(jìn)行威脅分析。

截取攻擊屬于被動攻擊，其本身并不改變定值單的數(shù)據(jù)內(nèi)容，也不會直接破壞電力系統(tǒng)的運行。同時，對截取攻擊進(jìn)行檢測極其困難，但截取攻擊后往往伴隨對報文的篡改和偽造，而篡改和偽造攻擊屬于主動攻擊，對其檢測較為容易。因此該系統(tǒng)著重對篡改攻擊和偽造攻擊進(jìn)行防范。篡改包括非授權(quán)人員對通信網(wǎng)絡(luò)中傳輸數(shù)據(jù)或?qū)Ψ?wù)器上關(guān)鍵文件的篡改。受篡改數(shù)據(jù)中的部分信息是真實的，因此可通過分析數(shù)據(jù)完整性來實現(xiàn)對篡改攻擊的檢測由于系統(tǒng)中通信節(jié)點數(shù)量與通信數(shù)據(jù)量都較為有限，且該系統(tǒng)通信網(wǎng)絡(luò)在物理上與外部網(wǎng)絡(luò)隔離。因此，無需考慮阻斷威脅。偽造攻擊即為攻擊者將生成的虛假信息直接發(fā)送給信息接收者。偽造信息的完整性較高而真實性欠缺，因此對于偽造攻擊的檢測可從真實性角度進(jìn)行分析。

綜上所述，結(jié)合繼電保護(hù)定值在線發(fā)放管理系統(tǒng)面臨的安全威脅，系統(tǒng)的安全性需求為保障繼電保護(hù)定值信息、設(shè)備參數(shù)、人員身份信息等數(shù)據(jù)的完整性、機(jī)密性、真實性與不可否認(rèn)性。為此，需設(shè)計相應(yīng)的安全防護(hù)方案滿足系統(tǒng)的安全需求。

2 系統(tǒng)方案與模塊設(shè)計

2.1 系統(tǒng)架構(gòu)

通過分析系統(tǒng)的功能需求與安全需求，對繼電保護(hù)定值在線發(fā)放在線管理系統(tǒng)進(jìn)行設(shè)計，所設(shè)計系統(tǒng)的架構(gòu)與主要功能框圖如圖1所示。

圖1 繼電保護(hù)定值在線發(fā)放管理系統(tǒng)框圖Fig.1 Diagram of online distribution management system for relay protection

系統(tǒng)包括定值在線流轉(zhuǎn)模塊、設(shè)備參數(shù)上傳模塊、身份認(rèn)證與訪問控制模塊和SSL/TLS協(xié)議模塊。

系統(tǒng)的基本功能即實現(xiàn)定值單的在線流轉(zhuǎn)，具體包括定值單的錄入生成、定值單在線校核、定值單在線下發(fā)與使用以及定值單駁回處理，這些功能由定值在線流轉(zhuǎn)模塊實現(xiàn)。設(shè)備參數(shù)上傳模塊的功能是上傳設(shè)備參數(shù)，參數(shù)上傳后由定值錄入人員進(jìn)行校核，完成校核后存入到數(shù)據(jù)庫，為定值錄入人員提供定值整定計算所需數(shù)據(jù)。身份認(rèn)證與訪問控制模塊賦予用戶角色對應(yīng)的權(quán)限并實現(xiàn)對于用戶身份的確認(rèn)。SSL/TLS協(xié)議通信模塊用以保證系統(tǒng)的通信安全。

(1)定值單的生成

生成定值單時，為提高效率，可從數(shù)據(jù)庫中查找原來的繼電保護(hù)定值單，對其整定值進(jìn)行修改，從而得到新的定值單。在定值單的生成過程中，定值單錄入人員可在未完成的定值單記錄中刪除錯誤記錄。為方便定值單錄入人員編輯定值單，定值單記錄支持以表格形式讀取與輸出，定值單在完成編輯后會自動更新。錄入人員在完成定值單編輯后將其發(fā)送給校核人員。

圖2 定值單在線流轉(zhuǎn)Fig.2 Online circulation of fixed value

(2)定值單的校核

定值單校核人員登陸系統(tǒng)后，進(jìn)入校核頁面進(jìn)行定值單校核工作。校核人員可查看的定值單分為待處理(即等待校核)定值單、近期定值單以及最近已完成校核定值單。系統(tǒng)可判斷定值單是否已完成校核。若定值單尚未完成校核，則需校核人員對其進(jìn)行計算與校核。完成校核任務(wù)后，校核人員可進(jìn)行如下選擇：校核通過并將定值單發(fā)給審批人員；直接下發(fā)給使用人員(校核通過且定值單審批人員不在崗，無法審批時使用)；駁回(發(fā)現(xiàn)問題時使用)，校核人員填寫駁回理由并將定值單返回給錄入人員。校核人員沒有修改定值單的權(quán)限，其無法完成對定值單的修改。

(3)定值單的審批

定值單校核通過后，系統(tǒng)將定值單發(fā)給審批人員進(jìn)行審批。在定值單審批界面，定值單分為待處理(即等待審批)定值單、最近已完成審批定值單與近期定值單。若定值單未發(fā)現(xiàn)問題，則審批人員審批通過定值單，并將定值單發(fā)送給相應(yīng)的廠站使用人員。若定值單未通過審批環(huán)節(jié)，則審批人員需填寫定值單駁回理由，駁回定值單給錄入人員。審批人員沒有修改定值單的權(quán)限，其無法完成對定值單的修改。

(4)定值單的使用

若定值單審批通過，則系統(tǒng)將定值單發(fā)放給廠站的定值單使用人員進(jìn)行繼電保護(hù)定值整定操作。系統(tǒng)需將定值單發(fā)放給相應(yīng)的廠站的定值單使用人員。定值單使用人員登錄系統(tǒng)后，系統(tǒng)根據(jù)記錄的用戶信息為使用人員分配相應(yīng)權(quán)限。使用人員可直接查看并打印定值單，并完成設(shè)備參數(shù)的整定任務(wù)，在完成參數(shù)整定后，使用人員點擊定值單使用完成信息進(jìn)行確認(rèn)，此時定值錄入人員收到提示，整個定值單的流轉(zhuǎn)過程就此完成。

設(shè)備參數(shù)上傳人員填寫設(shè)備參數(shù)并上傳，上傳成功后定值錄入人員對設(shè)備參數(shù)進(jìn)行校核。若設(shè)備參數(shù)經(jīng)校核后未發(fā)現(xiàn)錯誤，則再經(jīng)由錄入人員確認(rèn)后完成上傳設(shè)備參數(shù)任務(wù)。若校核時發(fā)現(xiàn)錯誤，則錄入人員駁回設(shè)備參數(shù)，設(shè)備參數(shù)上傳人員針對駁回意見進(jìn)行修改后重新上傳，直至校核通過。

考慮到春檢時需處理和發(fā)放的定值單較多，為避免分發(fā)不及時或分發(fā)錯誤，將批處理引入到系統(tǒng)中，具體處理過程如下：首先將需做春檢對比的舊數(shù)據(jù)庫進(jìn)行還原，然后與當(dāng)前數(shù)據(jù)庫中的現(xiàn)有定值根據(jù)“電壓等級>廠站選擇”的順序進(jìn)行逐條對比，自動生成春檢校核報告。除此之外，該系統(tǒng)還需實現(xiàn)將春檢定值按照“電壓等級>所屬單位”層次的批量打印將春檢校核完畢后的定值按“接收單位”批量流轉(zhuǎn)。打印完畢的春檢定值單可用于存檔，批量流轉(zhuǎn)的定值是接收單位一年來定值接收的匯總，這樣，充分發(fā)揮了計算機(jī)的計算能力，減輕了工作人員的負(fù)擔(dān)。

為在線監(jiān)測定值單狀態(tài)，考慮到人工發(fā)放定值單的過程中可能出現(xiàn)的各種復(fù)雜情形，本文采用布爾變量來記錄定值單的狀態(tài)。模塊中每個定值單都附加9個布爾變量，包括：s1、s2、s3、s4、s5、s6、s7、s8和s9。規(guī)定9個布爾變量分別表示8種狀態(tài)，如表1所示。

表1 定值單狀態(tài)與變量對照表Tab.1 Fixed value single state and variable

8種狀態(tài)具體的對應(yīng)關(guān)系為：①待上傳；②待校核；③校核通過(待批準(zhǔn))；④校核駁回；⑤直接下發(fā)；⑥批準(zhǔn)通過(待接收確認(rèn))；⑦批準(zhǔn)駁回；⑧已完成(定值接收完畢)。

在用戶對定值單進(jìn)行有效操作后，系統(tǒng)將更新所有布爾變量并上傳至服務(wù)器數(shù)據(jù)庫，并記錄用戶的活動日志。通過監(jiān)測定值單的生成、自動流轉(zhuǎn)、在線下發(fā)和設(shè)備參數(shù)的填報、上傳、訪問等各個流程，保障對定值單和設(shè)備參數(shù)的操作具有可追溯性。

2.2 系統(tǒng)認(rèn)證與訪問控制模塊設(shè)計

系統(tǒng)認(rèn)證用于確認(rèn)用戶身份，把正確的訪問權(quán)限賦予用戶。訪問控制用于限制用戶對系統(tǒng)資源的訪問，即控制完成身份認(rèn)證的系統(tǒng)用戶訪問系統(tǒng)文件資源。為確保用戶合法登錄及合理分配權(quán)限，本文所設(shè)計系統(tǒng)采用安全性較高的雙因子認(rèn)證，下面通過比較不同的訪問控制策略，結(jié)合本文實際情況設(shè)計訪問控制策略。

訪問控制策略主要有以下五類：自主訪問控制(DAC)、強(qiáng)制訪問控制(MAC)、基于角色的訪問控制(RBAC)、基于對象的訪問控制(OBAC)和基于任務(wù)的訪問控制(TBAC)。

DAC模型規(guī)定文件的創(chuàng)建者對文件擁有最高權(quán)限，其特點為主體可通過直接或間接的方式，把自己的權(quán)限轉(zhuǎn)移給另一主體。DAC的缺點在于其對木馬類攻擊的抵抗性很差，且DAC無法限制主體之間轉(zhuǎn)移權(quán)限，容易導(dǎo)致信息泄露。結(jié)合繼電保護(hù)定值在線發(fā)放管理系統(tǒng)的安全需求可知，該控制策略不適合應(yīng)用于該系統(tǒng)。

相對于DAC，MAC可保證被非授權(quán)者無法訪問客體，因此其對木馬類攻擊的抵抗性較強(qiáng)。同時由于MAC遵循“不許往上讀，不許向下寫”的原則，可保證關(guān)鍵信息的不外流。其缺點在于系統(tǒng)管理員的工作量龐大，管理缺乏靈活性，系統(tǒng)中訪問控制的信息量很大，一定程度上影響了繼電保護(hù)定值在線發(fā)放管理系統(tǒng)的連續(xù)工作能力，不便于系統(tǒng)的維護(hù)升級。因此，MAC控制策略不適合應(yīng)用于該系統(tǒng)。

RBAC將主體進(jìn)行分類，通過對不同類型的客體賦予主體不同類型的權(quán)限“模板”，一定程度上減輕了系統(tǒng)管理員的負(fù)擔(dān)。但其不足在于系統(tǒng)管理員仍需對每個主體賦予權(quán)限，并需要對權(quán)限進(jìn)行維護(hù)管理。在這種情況下，當(dāng)用戶達(dá)到幾百人甚至上千人時，系統(tǒng)管理員的工作量又將十分龐大，因而RBAC不適用于本系統(tǒng)。

OBAC允許訪問策略規(guī)則的繼承、重用和派生，并通過對用戶組的操作方便管理員修改主體權(quán)限，通過派生實現(xiàn)了新主體的權(quán)限分配，解決了用戶數(shù)目龐大時工作量大的問題。

以上的訪問控制策略都為靜態(tài)的，即若確定了主體s與客體o，那么權(quán)限p就是固定的?？紤]在繼電保護(hù)定值在線流轉(zhuǎn)過程中，需要先生成定值單，校核人員才能對其進(jìn)行讀取和校核，在完成校核任務(wù)后，審批人員才有審批權(quán)限，同樣地，在定值單通過審批后，定值單使用人員才有使用該定值單的權(quán)限；另一方面，在校核定值單的過程中，只允許校核人員訪問定值單，審批人員與使用人員都無法訪問定值單；類似地，在對定值單進(jìn)行審批時，校核人員與使用人員都無法讀取定值單。因此，考慮到系統(tǒng)實際的工作情況，本文所涉及繼電保護(hù)定值在線發(fā)放管理系統(tǒng)應(yīng)采用動態(tài)訪問控制策略。

基于任務(wù)的訪問控制策略(TBAC)是一種隨著數(shù)據(jù)庫與分布式計算而發(fā)展出的新型訪問控制策略，該策略的特點是可對在任務(wù)執(zhí)行中主體完成動態(tài)授權(quán)。TBAC采用五元組描述控制策略模型(S，O，P，L，AS)，權(quán)限P由主體S、客體O、生命期L與授權(quán)步AS共同決定。

結(jié)合本系統(tǒng)使用環(huán)境分析該TBAC模型中的五元組。系統(tǒng)用戶組S包括：系統(tǒng)管理員、定值單錄入、校核、審批、使用人員，以及廠站設(shè)備參數(shù)上傳人員。系統(tǒng)客體O為三類：繼電保護(hù)定值單、設(shè)備參數(shù)表、用戶信息表。系統(tǒng)用戶主要涉及的權(quán)限P有三種：讀取、寫入、駁回。授權(quán)步表示某時刻主體S對客體O被授予了權(quán)限P。生命期為授權(quán)步開始后，系統(tǒng)賦予主體權(quán)限的使用期限。

管理員負(fù)責(zé)系統(tǒng)中用戶的權(quán)限管理工作，與之對應(yīng)的客體為用戶信息表。定值單錄入、校核、審批與使用人員負(fù)責(zé)繼電保護(hù)定值單發(fā)放與流轉(zhuǎn)工作，與之相對應(yīng)的客體即為定值單。廠站設(shè)備參數(shù)上傳與定值錄入人員負(fù)責(zé)上傳設(shè)備參數(shù)，與之相對應(yīng)的客體為設(shè)備參數(shù)表。

TBAC在進(jìn)行權(quán)限分配時需按照一定規(guī)則，其在分配規(guī)則時所用符號如表2所示，在進(jìn)行角色指派時需遵循式(1)。

(?s∈S)(?t∈T)canexec(s,t)→actr(s)≠?

(1)

在TBAC中，主體角色不能為空，用戶本身也不具有任何權(quán)限。系統(tǒng)將任務(wù)t的權(quán)限賦予角色r，同時用戶通過角色r獲取任務(wù)t權(quán)限，進(jìn)而執(zhí)行t或訪問客體。式(2)為在認(rèn)證過程需遵循的規(guī)則：

(?s∈S)actr(s)?authr(s)

(2)

表2 用戶權(quán)限分配過程中的符號Tab.2 Symbol in the process of assigning rights

主體s所使用角色必須是由系統(tǒng)向主體授權(quán)過的角色。結(jié)合式(1)的角色指派規(guī)則可得式(3)所示系統(tǒng)授權(quán)規(guī)則：

(?s∈S)(?t∈T)canexec(s,t)→t∈trans(actr(s))

(3)

用戶在獲得角色授權(quán)之后，利用角色獲取相應(yīng)權(quán)限，在本系統(tǒng)中，管理員需為所有用戶確定不同角色，并且需要將權(quán)限分配給不同用戶，同時還需負(fù)責(zé)系統(tǒng)角色與系統(tǒng)權(quán)限的維護(hù)與更新工作，這在用戶數(shù)量較多的情況下，管理員工作量會十分龐大。因此，本系統(tǒng)采用TBAC策略中的角色繼承規(guī)則，式(4)表示角色rj繼承角色ri的前提：

(4)

式中ri>rj表示角色rj繼承角色ri。在角色rj繼承角色ri后，rj的權(quán)限集即為ri權(quán)限集的子集，即用戶只能以繼承的方式，將用戶對應(yīng)角色所具有的權(quán)限分發(fā)給其他用戶。本系統(tǒng)有六個主體用戶組，每個用戶組都需要添加組內(nèi)管理員。用戶在注冊時，需通過對應(yīng)高級別用戶的賬號登錄系統(tǒng)并進(jìn)行注冊。組內(nèi)管理員負(fù)責(zé)用戶組內(nèi)成員信息的添加、維護(hù)、更新與刪除。

結(jié)合以上對TBAC模型的權(quán)限分配規(guī)則，設(shè)計本模塊的具體實現(xiàn)方案。在系統(tǒng)認(rèn)證與訪問控制過程中，系統(tǒng)綜合用戶任務(wù)狀態(tài)以及角色信息庫，進(jìn)而將權(quán)限分配給相應(yīng)的用戶。任務(wù)工作狀態(tài)即為定值單的流轉(zhuǎn)狀態(tài)，用戶通過注冊繼而生成用戶角色信息庫。系統(tǒng)身份認(rèn)證與訪問控制流程如圖3所示，主要包括用戶登錄及雙因子身份認(rèn)證、用戶角色的賦予、訪問操作請求處理和賦予用戶權(quán)限四個過程。

(1)用戶登錄及雙因子身份認(rèn)證

圖3 系統(tǒng)身份認(rèn)證與訪問控制流程Fig.3 System identity authentication and access control

本系統(tǒng)設(shè)計了基于指紋與用戶名密碼的雙因子身份認(rèn)證方案。因此，系統(tǒng)需具備指紋信息的采集、上傳和比對功能。具體方案為：首先測試指紋識別終端是否連接成功，若連接成功后用戶需輸入用戶名密碼與指紋。系統(tǒng)通過將輸入的信息與數(shù)據(jù)庫中存儲的對應(yīng)用戶信息進(jìn)行比較。若信息符合則出現(xiàn)認(rèn)證成功的提示，從而完成系統(tǒng)用戶身份的可靠性驗證。為保護(hù)用戶信息并便于實施訪問控制策略，系統(tǒng)將用戶信息存入到應(yīng)用程序中。同時為便于管理員進(jìn)行安全審查，系統(tǒng)數(shù)據(jù)庫會記錄下用戶的登錄身份與時間，進(jìn)而生成系統(tǒng)日志，為系統(tǒng)提供了不可否認(rèn)性驗證，防止內(nèi)部人員通過非法登錄并截取、偽造與篡改數(shù)據(jù)。

(2)賦予用戶角色

身份認(rèn)證成功后，系統(tǒng)比對用戶信息與系統(tǒng)內(nèi)的角色信息，從而判斷用戶的身份信息，賦予登錄用戶角色，同時通過角色任務(wù)權(quán)限庫為訪問控制模塊提供角色的權(quán)限信息。

(3)處理訪問請求

用戶提出訪問請求后，系統(tǒng)將該請求提交給訪問請求處理模塊。一方面，訪問請求處理模塊將用戶、角色以及所要訪問的客體資源等信息提交給訪問控制模塊；另一方面，系統(tǒng)將用戶請求提交給任務(wù)狀態(tài)記錄子模塊，任務(wù)工作狀態(tài)即為定值單在線流轉(zhuǎn)狀態(tài)的數(shù)據(jù)表。系統(tǒng)通過任務(wù)工作狀態(tài)將任務(wù)信息庫中的數(shù)據(jù)信息激活，并向訪問控制模塊提供授權(quán)步的相關(guān)條件，訪問控制模塊根據(jù)角色任務(wù)權(quán)限庫所提供的角色權(quán)限并判斷是否用戶是否滿足授權(quán)步條件，從而作出決策，并將結(jié)果返回給訪問請求處理模塊。

(4)賦予權(quán)限

訪問請求處理模塊依據(jù)訪問策略的決策結(jié)果，將相應(yīng)權(quán)限賦予用戶，完成系統(tǒng)認(rèn)證與訪問控制，用戶根據(jù)權(quán)限訪問客體資源文件并完成相關(guān)操作。

2.3 SSL/TLS協(xié)議通信模塊設(shè)計

為確保信息在傳輸時的安全性，需構(gòu)建安全可靠的信道，該系統(tǒng)采用SSL/TLS協(xié)議進(jìn)行安全信道的構(gòu)建。SSL/TLS協(xié)議通信模塊需實現(xiàn)的功能為：(1)對數(shù)據(jù)進(jìn)行加密，防止攻擊者竊取在傳輸過程中的報文數(shù)據(jù)；(2)保證數(shù)據(jù)完整性，確保系統(tǒng)能夠識別出被篡改的數(shù)據(jù)；(3)認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器。本文設(shè)計的SSL/TLS協(xié)議的認(rèn)證部分采用HMAC模式下MD5哈希算法實現(xiàn)，同時協(xié)議規(guī)定加密部分采用對稱與非對稱加密算法相結(jié)合的方式，利用RSA算法輔助生成對稱加密算法的會話密鑰，采用AES加密算法在CBC模式下進(jìn)行數(shù)據(jù)加密。下面詳細(xì)分析SSL/TLS協(xié)議。

SSL/TLS協(xié)議棧包括兩個子層，第一層包含三個子協(xié)議，分別為握手協(xié)議、警報協(xié)議與修改密碼規(guī)范協(xié)議，第二層是記錄協(xié)議。本文采用的握手協(xié)議用于通信雙方的身份認(rèn)證、確定加密算法以及發(fā)放與交換密鑰以下對握手協(xié)議實現(xiàn)過程進(jìn)行分析，可分為圖4所示的四個階段。

(1)在客戶端和服務(wù)器之間建立SSL連接，客戶端將MClient_hellow報文發(fā)送給服務(wù)器，建立握手：

MClient_hello=vers||rand1||sess_id||cipher_list||comp_list

(5)

式中vers為客戶端SSL版本號；comp_list為支持壓縮算法列表；rand1為由隨機(jī)128bit與t時間戳組成的隨機(jī)數(shù)；sess_id表示會話標(biāo)識號；cipher_list表示客戶端可支持的加密算法列表。服務(wù)器在收到信息后向客戶端發(fā)送式(6)的報文。

MServer_hello=vers||rand2||sess_id||cipher||comp

(6)

式中cipher兩端均支持的加密算法，本系統(tǒng)規(guī)定為RSA；vers為服務(wù)器及客戶端能夠支持的最高版本；comp為由服務(wù)器選擇的通信雙方都支持的算法；rand2為隨機(jī)128位二進(jìn)制數(shù)與由服務(wù)器生成的時間戳組合而成的隨機(jī)數(shù)。

(2)服務(wù)器認(rèn)證過程。該階段是握手協(xié)議的關(guān)鍵部分。服務(wù)器將服務(wù)器證書發(fā)送給客戶端，該證書包括數(shù)字簽名與所要發(fā)放的公鑰，報文如下：

圖4 SSL/TLS握手協(xié)議Fig.4 SSL/TLS handshake protocol

MCertificate=server_cert

(7)

式中server_cert表示服務(wù)器證書。

服務(wù)器將驗證請求發(fā)送給客戶端，其交換密鑰的報文如下：

MServer_key_exchange=mod||exp||E(KS,[Hash(rand1||rand2||mod||exp)])

(8)

式中KS為服務(wù)器端的公鑰所對應(yīng)的私鑰；mod為RSA算法中公鑰模；exp為RSA算法中公鑰指數(shù)。

采用哈希函數(shù)對mod、exp、rand1與rand2進(jìn)行處理并生成消息摘要后用服務(wù)器私鑰進(jìn)行加密，利用挑戰(zhàn)-應(yīng)答機(jī)制以驗證服務(wù)器來源。客戶端證書的請求報文為可選報文，在需要對客戶端進(jìn)行驗證的情況下，服務(wù)器要求客戶端提供證書并對證書的格式內(nèi)容作出要求。本系統(tǒng)的客戶端采用基于用戶名密碼以及指紋的雙因子身份認(rèn)證而無需客戶端證書，因此在握手階段，可省略證書請求報文與客戶端證書消息報文。

服務(wù)器向客戶端發(fā)送式(9)所示的信息表示第二階段即服務(wù)器身份認(rèn)證結(jié)束。

MServer_hello_done=end_round2

(9)

服務(wù)器端身份認(rèn)證的作用為：客戶端獲取服務(wù)器提供的證書后，基于該證書加密后續(xù)兩階段的報文信息，服務(wù)器需采用相應(yīng)私鑰以完成信息的獲取，否則就無法進(jìn)行會話密鑰的協(xié)商，確保了定值和設(shè)備參數(shù)來源的不可否認(rèn)性。

(3)客戶端向服務(wù)器端發(fā)放客戶端證書進(jìn)行身份認(rèn)證，在前面要求提供證書的條件下，向服務(wù)器端提供合格的客戶端證書。

MClient_key_exchange=pre_master_secret

(10)

式中pre_master_secret為客戶端向服務(wù)器端發(fā)放預(yù)主密鑰。

服務(wù)器端采用RSA公鑰加密48位的隨機(jī)數(shù)生成預(yù)主密鑰，在服務(wù)器端需用私鑰進(jìn)行解密以防止被攻擊者監(jiān)聽，并階段性對服務(wù)器端進(jìn)行身份驗證。

MCertificate_verify=Hash(mastr||opad||

Hash(messages||mastr||ipad))

(11)

式中opad和ipad為常值，分別為0x5C和0x36；messages為上述報文的連接信息，mastr為由rand1、rand2、session_id與pre_master_secret生成的主密鑰。

圖5表示生成mastr的過程，采用SHA-1與MD5算法處理四個參數(shù)，為確保密鑰生成的隨機(jī)性，采用Diffie-Hellman方法生成秘鑰。

圖5 主密鑰生成過程Fig.5 Master key generation process

(4)完成服務(wù)器端握手協(xié)議。該階段包含四部分，即客戶端向服務(wù)器發(fā)送兩條報文，服務(wù)器回復(fù)給客戶端兩條報文。其中兩條完成報文為固定格式?？蛻舳烁淖兠艽a規(guī)格報文如下：

MCert_change_cipher=Hash(mastr||opad||

Hash(messages||msg||mastr||ipad))

(12)

式中msg為報文應(yīng)用密碼參數(shù)，本消息中為0x434C4E54。

(a)將報文分割為最大214字節(jié)的數(shù)據(jù)塊，在各數(shù)據(jù)塊中插入報文記錄，該報文記錄包括長度、版本號、數(shù)據(jù)字段和類型；

(b)選擇無損壓縮算法對數(shù)據(jù)進(jìn)行壓縮，需確保壓縮后增加報文記錄的長度超過1024 byte?？紤]到分組密碼算法要求，若發(fā)送方本身未選擇壓縮數(shù)據(jù)，則仍需對數(shù)據(jù)進(jìn)行填充等處理；

(c)計算消息認(rèn)證碼MAC，用以確保分組數(shù)據(jù)的完整性，用到的算法采用在握手協(xié)議中確定的256位SHA-1算法；

(d)對壓縮數(shù)據(jù)及MAC進(jìn)行加密，加密算法也由握手協(xié)議確定；

(e)完善SSL記錄，即對處理過的數(shù)據(jù)添加封裝。

綜上所述，采用SSL/TLS協(xié)議可有效抵御截取、篡改與偽造攻擊。攻擊者通過截取獲取通信密文后，由于其無法得知密鑰，同樣無法破解密文獲取定值與設(shè)備參數(shù)。服務(wù)器可識別篡改與偽造后的信息。因此，通過以上安全方案保障了信息的機(jī)密性和完整性。

3 系統(tǒng)實現(xiàn)

基于上述設(shè)計的系統(tǒng)方案和各個模塊，采用C#語言和SQL數(shù)據(jù)庫，基于C/S結(jié)構(gòu)，開發(fā)了繼電保護(hù)定值在線發(fā)放管理系統(tǒng)，所開發(fā)的系統(tǒng)軟件的界面結(jié)構(gòu)圖如圖6所示。利用.NET開發(fā)工具中ADO.NET技術(shù)實現(xiàn)數(shù)據(jù)庫訪問功能。該系統(tǒng)支持將服務(wù)器上的數(shù)據(jù)庫文件和日志文件打包備份到用戶本地上。通過利用數(shù)據(jù)庫cmdshell功能向數(shù)據(jù)庫所在的服務(wù)器發(fā)送DOS命令直接操作服務(wù)器進(jìn)行實現(xiàn)。由于系統(tǒng)所在內(nèi)部局域網(wǎng)與外網(wǎng)隔離，不便利用網(wǎng)絡(luò)申請SSL/TLS證書，因此系統(tǒng)采用OpenSSL開源安全套接字層密碼庫生成SSL/TLS證書。

所設(shè)計的系統(tǒng)定值單在線編輯界面如圖7所示。在定值錄入界面上，“定值狀態(tài)一覽”提供定值狀態(tài)的直觀顯示，定值單狀態(tài)如圖8所示。

圖6 系統(tǒng)軟件界面結(jié)構(gòu)圖Fig.6 System software interface structure diagram

圖7 定值單編輯界面Fig.7 fixed value editing interface

圖8 定值單狀態(tài)圖Fig.8 Fixed value state

4 結(jié)束語

采用C#為語言、SQL數(shù)據(jù)庫和OpenSSL開發(fā)工具，開發(fā)了由定值在線流轉(zhuǎn)、設(shè)備參數(shù)表上傳、系統(tǒng)認(rèn)證與訪問控制、SSL/TLS協(xié)議通信等模塊組成的繼電保護(hù)定值在線發(fā)放管理系統(tǒng)；設(shè)計了雙因子身份認(rèn)證方案、基于任務(wù)的訪問控制策略、基于SSL/TLS協(xié)議的安全信道和基于安全信道的數(shù)據(jù)加密/解密方案，并由此構(gòu)成了系統(tǒng)安全防護(hù)方案。目前，所開發(fā)系統(tǒng)已在某地區(qū)電網(wǎng)獲得了實際應(yīng)用。實際應(yīng)用效果表明，該系統(tǒng)實現(xiàn)了定值單與設(shè)備參數(shù)的在線流轉(zhuǎn)，并能對整個繼電保護(hù)定值在線發(fā)放流程進(jìn)行跟蹤，預(yù)防和消除了通過通信網(wǎng)絡(luò)修改設(shè)備繼電保護(hù)定值的安全隱患，提高了定值單發(fā)放的安全性與可靠性，滿足了系統(tǒng)的功能需求與安全需求。