繼電保護(hù)定值在線發(fā)放管理系統(tǒng)及其安全防護(hù)

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

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

0 引 言

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

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

針對(duì)繼電保護(hù)定值在線發(fā)放的準(zhǔn)確性與安全性這一問題，國內(nèi)外進(jìn)行了廣泛研究。文獻(xiàn)[6-7]在分析電力系統(tǒng)通信網(wǎng)絡(luò)環(huán)境的基礎(chǔ)上，對(duì)保護(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)限。同時(shí)，為便于管理員進(jìn)行安全審計(jì)，系統(tǒng)會(huì)將各用戶的操作日志記錄下來。文獻(xiàn)[10]研究設(shè)置防火墻以過濾外部人員非授權(quán)訪問繼電保護(hù)數(shù)據(jù)服務(wù)器的行為。然而，通過對(duì)上述文獻(xiàn)分析可知，現(xiàn)有的訪問控制策略僅能夠阻擋外部人員的非授權(quán)訪問；利用數(shù)字簽名可保證數(shù)據(jù)來源的正確性，但定值的實(shí)時(shí)性無法保證，因此繼電保護(hù)定值也面臨著重放攻擊的威脅；此外，部分系統(tǒng)將加密算法所使用的密鑰也寫入到程序中，密鑰安全性無法得到保證。

為解決某地區(qū)電力調(diào)度中心繼電保護(hù)定值單長期依靠人工發(fā)放工作效率低的問題，在考慮上述安全問題的基礎(chǔ)上，擬設(shè)計(jì)具有定值單錄入、定值單在線校核與審批、設(shè)備參數(shù)上傳等功能的繼電保護(hù)定值在線發(fā)放管理系統(tǒng)；基于SSL/TLS協(xié)議構(gòu)建系統(tǒng)安全信道，設(shè)計(jì)系統(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ǔ)上，實(shí)現(xiàn)定值錄入、定值校核、定值批準(zhǔn)、定值接收、設(shè)備參數(shù)上傳、設(shè)備參數(shù)接收、定值單修改和定值單駁回等功能，并可實(shí)時(shí)查看、追蹤定值單所處的狀態(tài)。

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

在定值單較多的春檢階段易出現(xiàn)分發(fā)不及時(shí)或分發(fā)錯(cuò)誤等問題，因此，該系統(tǒng)需實(shí)現(xiàn)春檢校核、批量打印、批量流轉(zhuǎn)等功能，實(shí)現(xiàn)同質(zhì)化的批量處理。同時(shí)，為更加高效、簡明、安全地實(shí)現(xiàn)用戶的添加、刪除、修改，需建立層次分明的用戶管理機(jī)制。同時(shí)為便于記錄的管理，系統(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)行威脅分析。

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

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

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

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

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

(1)定值單的生成

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

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

(2)定值單的校核

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

(3)定值單的審批

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

(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ù)整定后，使用人員點(diǎn)擊定值單使用完成信息進(jìn)行確認(rèn)，此時(shí)定值錄入人員收到提示，整個(gè)定值單的流轉(zhuǎn)過程就此完成。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于任務(wù)的訪問控制策略(TBAC)是一種隨著數(shù)據(jù)庫與分布式計(jì)算而發(fā)展出的新型訪問控制策略，該策略的特點(diǎn)是可對(duì)在任務(wù)執(zhí)行中主體完成動(dòng)態(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)步表示某時(shí)刻主體S對(duì)客體O被授予了權(quán)限P。生命期為授權(quán)步開始后，系統(tǒng)賦予主體權(quán)限的使用期限。

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

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

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

(1)

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

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

(2)

表2 用戶權(quán)限分配過程中的符號(hào)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)限分配給不同用戶，同時(shí)還需負(fù)責(zé)系統(tǒng)角色與系統(tǒng)權(quán)限的維護(hù)與更新工作，這在用戶數(shù)量較多的情況下，管理員工作量會(huì)十分龐大。因此，本系統(tǒng)采用TBAC策略中的角色繼承規(guī)則，式(4)表示角色rj繼承角色ri的前提：

(4)

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

結(jié)合以上對(duì)TBAC模型的權(quán)限分配規(guī)則，設(shè)計(jì)本模塊的具體實(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)，用戶通過注冊(cè)繼而生成用戶角色信息庫。系統(tǒng)身份認(rèn)證與訪問控制流程如圖3所示，主要包括用戶登錄及雙因子身份認(rèn)證、用戶角色的賦予、訪問操作請(qǐng)求處理和賦予用戶權(quán)限四個(gè)過程。

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

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

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

(2)賦予用戶角色

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

(3)處理訪問請(qǐng)求

用戶提出訪問請(qǐng)求后，系統(tǒng)將該請(qǐng)求提交給訪問請(qǐng)求處理模塊。一方面，訪問請(qǐng)求處理模塊將用戶、角色以及所要訪問的客體資源等信息提交給訪問控制模塊；另一方面，系統(tǒng)將用戶請(qǐ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é)果返回給訪問請(qǐng)求處理模塊。

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

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

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

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

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

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

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

(5)

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

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ù)器生成的時(shí)間戳組合而成的隨機(jī)數(shù)。

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

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

MCertificate=server_cert

(7)

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

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

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

(8)

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

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

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

MServer_hello_done=end_round2

(9)

服務(wù)器端身份認(rèn)證的作用為：客戶端獲取服務(wù)器提供的證書后，基于該證書加密后續(xù)兩階段的報(bào)文信息，服務(wù)器需采用相應(yīng)私鑰以完成信息的獲取，否則就無法進(jìn)行會(huì)話密鑰的協(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)聽，并階段性對(duì)服務(wù)器端進(jìn)行身份驗(yàn)證。

MCertificate_verify=Hash(mastr||opad||

Hash(messages||mastr||ipad))

(11)

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

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

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

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

MCert_change_cipher=Hash(mastr||opad||

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

(12)

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

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

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

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

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

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

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

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

基于上述設(shè)計(jì)的系統(tǒng)方案和各個(gè)模塊，采用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ù)實(shí)現(xiàn)數(shù)據(jù)庫訪問功能。該系統(tǒng)支持將服務(wù)器上的數(shù)據(jù)庫文件和日志文件打包備份到用戶本地上。通過利用數(shù)據(jù)庫cmdshell功能向數(shù)據(jù)庫所在的服務(wù)器發(fā)送DOS命令直接操作服務(wù)器進(jìn)行實(shí)現(xiàn)。由于系統(tǒng)所在內(nèi)部局域網(wǎng)與外網(wǎng)隔離，不便利用網(wǎng)絡(luò)申請(qǐng)SSL/TLS證書，因此系統(tǒng)采用OpenSSL開源安全套接字層密碼庫生成SSL/TLS證書。

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