基于WEB的應用系統(tǒng)安全專項方案_第1頁
基于WEB的應用系統(tǒng)安全專項方案_第2頁
基于WEB的應用系統(tǒng)安全專項方案_第3頁
基于WEB的應用系統(tǒng)安全專項方案_第4頁
基于WEB的應用系統(tǒng)安全專項方案_第5頁
已閱讀5頁,還剩20頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

第二章系統(tǒng)安全需求分析本章從數(shù)據(jù)安全和業(yè)務邏輯安全兩個角度對應用系統(tǒng)安全進行需求分析,關(guān)鍵包含保密性需求、完整性需求、可用性需求三部分;隨即對業(yè)務邏輯安全需求進行了分析,包含身份認證、訪問控制、交易反復提交控制、異步交易處理、交易數(shù)據(jù)不可否認性、監(jiān)控和審計等多個方面;最終還分析了系統(tǒng)中部分其它安全需求。2.1數(shù)據(jù)安全需求2.1.1 數(shù)據(jù)保密性需求數(shù)據(jù)保密性要求數(shù)據(jù)只能由授權(quán)實體存取和識別,預防非授權(quán)泄露。從現(xiàn)在中國應用安全案例統(tǒng)計數(shù)據(jù)來看,數(shù)據(jù)保密性是最易受到攻擊一個方面,通常表現(xiàn)為用戶端發(fā)生數(shù)據(jù)泄密,包含用戶基礎信息、賬戶信息、登錄信息等泄露。在應用系統(tǒng)中,數(shù)據(jù)保密性需求通常關(guān)鍵表現(xiàn)在以下多個方面:A.用戶端和系統(tǒng)交互時輸入各類密碼:包含系統(tǒng)登錄密碼、轉(zhuǎn)賬密碼、憑證查詢密碼、憑證交易密碼等必需加密傳輸及存放,這些密碼在應用系統(tǒng)中只能以密文方法存在,其明文形式能且只能由其正當主體能夠識別。以網(wǎng)銀系統(tǒng)為例,在網(wǎng)銀系統(tǒng)中,通常存有四種密碼:系統(tǒng)登錄密碼、網(wǎng)銀轉(zhuǎn)賬密碼、柜面交易密碼及一次性密碼。系統(tǒng)登錄密碼用來認證目前登錄者為指定登錄名正當用戶,網(wǎng)銀用戶登錄密碼和網(wǎng)銀轉(zhuǎn)賬密碼由用戶在柜面開戶時指定,用戶在首次登錄網(wǎng)銀系統(tǒng)時,系統(tǒng)必需強制用戶修改初始密碼,通常要求長度不得少于六位數(shù),且不能是類似于111111、1234567、9876543等簡單數(shù)字序列,系統(tǒng)將進行檢驗。網(wǎng)銀轉(zhuǎn)賬密碼是指網(wǎng)銀系統(tǒng)為鞏固用戶資金安全,在包含資金變動交易中對用戶身份進行了再認證,要求用戶輸入預設密碼,網(wǎng)銀交易密碼僅針對個人用戶使用,企業(yè)用戶沒有網(wǎng)銀交易密碼。建立多重密碼機制,將登錄密碼和網(wǎng)銀轉(zhuǎn)賬密碼分開管理,有利于加強密碼安全性。因為用戶在使用網(wǎng)銀時每次全部必需先提供登錄密碼,故登錄密碼暴露機會較多,安全性相對較弱;但登錄網(wǎng)銀用戶并不是每次全部會操作賬戶資金,所以專門設定網(wǎng)銀轉(zhuǎn)賬密碼可加強賬戶安全性。網(wǎng)銀轉(zhuǎn)賬密碼在網(wǎng)銀開戶時設定,網(wǎng)銀用戶在系統(tǒng)中作轉(zhuǎn)賬支付、理財、代繳費等資金變動類交易時使用。柜面交易密碼是指用戶在銀行柜面辦理儲蓄時,針對儲蓄憑證(如卡折、存單等)而設密碼。柜面交易密碼常見于POS系統(tǒng)支付時、ATM取款時、憑證柜面取款時,柜面交易密碼一個顯著特征是它現(xiàn)在只能是六位數(shù)字,這是因為現(xiàn)在柜面密碼輸入設備限制而造成。柜面交易密碼和上述網(wǎng)銀轉(zhuǎn)賬密碼區(qū)分在于:網(wǎng)銀轉(zhuǎn)賬密碼和系統(tǒng)登錄密碼全部產(chǎn)生于網(wǎng)銀系統(tǒng),儲存在網(wǎng)銀系統(tǒng)中,僅限網(wǎng)銀系統(tǒng)中認證使用;而柜面交易密碼產(chǎn)生于銀行柜臺,能夠在外圍渠道如ATM、電話銀行、自助終端上修改,它保留在銀行關(guān)鍵系統(tǒng)中,供外圍各個渠道系統(tǒng)共同使用。另外網(wǎng)銀轉(zhuǎn)賬密碼能夠有非數(shù)字字符組成,而柜面交易密碼只能是六位數(shù)字。網(wǎng)銀中使用到柜面交易密碼交易包含:網(wǎng)銀開戶、加掛賬戶。一次性密碼由用戶智能卡、令牌卡產(chǎn)生,或由動態(tài)密碼系統(tǒng)產(chǎn)生經(jīng)過短信方法發(fā)送到用戶注冊手機上。一次性密碼作用和網(wǎng)銀轉(zhuǎn)賬密碼相同,適用場所也相同。一次性密碼在農(nóng)商行網(wǎng)銀系統(tǒng)中是可選安全服務,用戶需到柜面辦理開通手續(xù)才能使用,沒有開通一次性密碼服務用戶必需設定網(wǎng)銀交易密碼,開通一次性密碼服務用戶則無需設定網(wǎng)銀交易密碼,要求網(wǎng)銀系統(tǒng)自動判定并提醒用戶在某個交易中是要輸入網(wǎng)銀交易密碼還是提醒一次性密碼。B.應用系統(tǒng)和其它系統(tǒng)進行數(shù)據(jù)交換時在特定安全需求下需進行端對端加解密處理。這里數(shù)據(jù)加密關(guān)鍵是為了預防交易數(shù)據(jù)被銀行內(nèi)部人士截取利用,具體通訊加密方案參考應用系統(tǒng)特定需求。2.1.2 數(shù)據(jù)完整性需求數(shù)據(jù)完整性要求預防非授權(quán)實體對數(shù)據(jù)進行非法修改。用戶在跟應用系統(tǒng)進行交互時,其輸入設備如鍵盤、鼠標等有可能被木馬程序偵聽,輸入數(shù)據(jù)遭到截取修改后被提交到應用系統(tǒng)中,如原本用戶準備向A賬戶轉(zhuǎn)一筆資金在交易數(shù)據(jù)遭到修改后就被轉(zhuǎn)到B賬戶中了。一樣威脅還存在于交易數(shù)據(jù)傳輸過程中,如在用戶向應用系統(tǒng)提交網(wǎng)絡傳輸過程中或應用系統(tǒng)跟第三方等其它系統(tǒng)通訊過程中,另外存放在應用系統(tǒng)數(shù)據(jù)庫中數(shù)據(jù)也有可能遭到非法修改,如SQL注入攻擊等。2.1.3 數(shù)據(jù)可用性需求數(shù)據(jù)可用性要求數(shù)據(jù)對于授權(quán)實體是有效、可用,確保授權(quán)實體對數(shù)據(jù)正當存取權(quán)利。對數(shù)據(jù)可用性最經(jīng)典攻擊就是拒絕式攻擊(DoS)和分布式拒絕攻擊,二者全部是經(jīng)過大量并發(fā)惡意請求來占用系統(tǒng)資源,致使正當用戶無法正常訪問目標系統(tǒng),如SYNFlood攻擊等,將會直接造成其它用戶無法登錄系統(tǒng)。另外,應用登錄機器人對用戶密碼進行窮舉攻擊也會嚴重影響系統(tǒng)可用性。2.2業(yè)務邏輯安全需求業(yè)務邏輯安全關(guān)鍵是為了保護應用系統(tǒng)業(yè)務邏輯根據(jù)特定規(guī)則和步驟被存取及處理。2.2.1 身份認證需求身份認證就是確定某個個體身份過程。系統(tǒng)經(jīng)過身份認證過程以識別個體用戶身份,確保個體為所宣稱身份。應用系統(tǒng)中身份認證可分為單向身份認證和雙向身份認證,單向身份認證是指應用系統(tǒng)對用戶進行認證,而雙向身份認證則指應用系統(tǒng)和用戶進行相互認證,雙向身份認證可有效預防“網(wǎng)絡釣魚”等假網(wǎng)站對真正系統(tǒng)冒充。應用服務器采取數(shù)字證書,向用戶端提供身份認證,數(shù)字證書要求由權(quán)威、獨立、公正第三方機構(gòu)頒發(fā);系統(tǒng)為用戶端提供兩種可選身份認證方案,服務器端對用戶端進行多重身份認證,要求充足考慮到用戶端安全問題。將用戶端用戶身份認證和賬戶身份認證分開進行,在用戶登錄系統(tǒng)時,采取單點用戶身份認證,在用戶提交更新類、管理類交易請求時,再次對用戶操作進行認證或?qū)τ脩羯矸葸M行二次認證,以確保用戶信息安全。2.2.2 訪問控制需求訪問控制要求了主體對客體訪問限制,并在身份識別基礎上,依據(jù)身份對提出資源訪問請求加以控制。訪問控制是應用系統(tǒng)中關(guān)鍵安全策略,它關(guān)鍵任務是確保應用系統(tǒng)資源不被非法訪問。主體、客體和主體對客體操作權(quán)限組成訪問控制機制三要素。訪問控制策略能夠劃分為自主訪問控制、強制訪問控制和基于角色訪問控制三種。交易反復提交控制需求交易反復提交就是同一個交易被數(shù)次提交給應用系統(tǒng)。查詢類交易被反復提交將會無故占用更多系統(tǒng)資源,而管理類或金融類交易被反復提交后,后果則會嚴重多,譬如一筆轉(zhuǎn)賬交易被提交兩次則將造成用戶賬戶被轉(zhuǎn)出兩筆相同額資金,顯然用戶只想轉(zhuǎn)出一筆。交易被反復提交可能是無意,也有可能是有意:A.用戶誤操作。在B/S結(jié)構(gòu)中,從用戶端來看,服務器端對用戶端響應總有一定延遲,這在一些交易處理上表現(xiàn)更為顯著,尤其是那些包含多個系統(tǒng)交互、遠程訪問、數(shù)據(jù)庫全表掃描、頁面數(shù)據(jù)署名等交易,這種延遲通常全部會在5至7秒以上。這時用戶有可能在頁面已提交情況下,再次點擊了提交按鈕,這時將會造成交易被反復提交。B.被提交交易數(shù)據(jù)有可能被拿來作重放攻擊。應用系統(tǒng)必需對管理類和金融類交易提交次數(shù)進行控制,這種控制即要有效杜絕用戶誤操作,還不能影響用戶正常情況下對某個交易數(shù)次提交。比如說:當某個用戶在10秒內(nèi)提交了兩筆相同轉(zhuǎn)賬業(yè)務,則系統(tǒng)必需對此進行控制;其次,當用戶在第一筆轉(zhuǎn)賬業(yè)務完成后,再作另一筆數(shù)據(jù)相同轉(zhuǎn)賬時,則系統(tǒng)不能對此進行誤控制。這里判定依據(jù)就是交易反復提交控制因子a,當交易提交間隔小于a時,系統(tǒng)認為這是反復提交,提交間隔大于a則不作處理,控制因子大小由應用系統(tǒng)業(yè)務人員決定,系統(tǒng)應可對其進行配置化管理。2.2.4 異步交易處理需求所謂異步交易就是指那些錄入和提交不是同時完成交易,這里同時是指用戶端在錄入交易數(shù)據(jù)和提交交易過程中,應用系統(tǒng)服務器端并沒有對錄入數(shù)據(jù)進行持久化保留,而異步交易在系統(tǒng)處理過程中,錄入和提交時間上發(fā)生在兩個相分離階段,在兩階段之間,應用系統(tǒng)對錄入數(shù)據(jù)進行了持久化保留。因為異步交易是被系統(tǒng)分兩階段受理,這就包含到以下三個方面問題:錄入和提交關(guān)系管理。怎樣確保提交數(shù)據(jù)就是用戶當初錄入數(shù)據(jù)。怎樣統(tǒng)計交易在兩階段日志狀態(tài)。錄入和提交關(guān)系定義不妥將會造成交易錄入和提交被同時完成而違反了業(yè)務處理步驟,錄入數(shù)據(jù)被系統(tǒng)保留后有可能遭到非法篡改,非異步交易實施后日志狀態(tài)不會被更新而異步交易在提交后日志狀態(tài)將會被更新。應用系統(tǒng)中需要定義成異步交易通常有以下兩類:需要授權(quán)交易。出于業(yè)務管理和業(yè)務安全方面考慮,大部分管理類和金融類交易全部需要經(jīng)過一定授權(quán)步驟后方能被提交。部分定時交易,如預約轉(zhuǎn)賬等。預約一筆在周三轉(zhuǎn)賬預約轉(zhuǎn)賬有可能是周一被錄入,用戶在錄入后,預約轉(zhuǎn)賬數(shù)據(jù)將被網(wǎng)銀系統(tǒng)保留直到周三這筆轉(zhuǎn)賬才會真正發(fā)生。應用系統(tǒng)必需定義簡單、清楚、易維護錄入和提交關(guān)系模型,確保被保留錄入數(shù)據(jù)不會被非法篡改,同時要求異步交易日志狀態(tài)是明確,不應出現(xiàn)錄入和提交相矛盾日志狀態(tài)。2.2.5 交易數(shù)據(jù)不可否認性需求交易數(shù)據(jù)不可否認性是指應用系統(tǒng)用戶不能否認其所署名數(shù)據(jù),用戶對交易數(shù)據(jù)署名是經(jīng)過應用系統(tǒng)使用用戶數(shù)字證書來完成。數(shù)字證書應用為交易數(shù)據(jù)不可否認性提供了技術(shù)支持,而電子署名法頒布為交易數(shù)據(jù)不可否認性提供了法律基礎。在應用系統(tǒng)中通常要求對全部管理類和金融類交易進行數(shù)字署名,以防用戶事后對交易或交易數(shù)據(jù)抵賴。應用系統(tǒng)需同時保留用戶錄入原始數(shù)據(jù)和署名后數(shù)據(jù),保留期限依業(yè)務部門具體要求而定??紤]到系統(tǒng)性能和對用戶響應問題,應用系統(tǒng)可只簽和交易相關(guān)關(guān)鍵數(shù)據(jù),支付類交易只對付款人賬號、付款金額、收款人姓名、收款人賬號、收款人開戶行五個字段進行數(shù)字署名就能夠了。2.2.6 監(jiān)控和審計需求安全等級要求高應用系統(tǒng)應提供對系統(tǒng)進行實時監(jiān)控功效,監(jiān)控內(nèi)容包含系統(tǒng)目前登錄用戶、用戶類型、用戶正在訪問交易、用戶登錄IP等。對金融類、管理類交易和應用系統(tǒng)登錄交易需要完整地統(tǒng)計用戶訪問過程,統(tǒng)計關(guān)鍵元素包含:用戶登錄名、登錄IP、交易日期立即間、交易名稱、交易相關(guān)數(shù)據(jù)等,對有授權(quán)步驟交易要求完整統(tǒng)計授權(quán)經(jīng)過,授權(quán)統(tǒng)計和交易統(tǒng)計分開存放。2.3其它安全需求2.3.1登錄控制需求登錄通常是應用系統(tǒng)關(guān)鍵交易,系統(tǒng)經(jīng)過登錄交易對用戶身份進行認證。針對不一樣角色用戶指定不一樣登錄策略:最小權(quán)限集用戶,可使用用戶登錄名+靜態(tài)登錄密碼+圖形識別碼方法登錄。低安全性。一般權(quán)限集用戶,可使用用戶登錄名+動態(tài)登錄密碼+數(shù)圖形識別碼方法登錄。高權(quán)限集用戶,可使用用戶登錄名+數(shù)字證書+靜態(tài)密碼+數(shù)圖形識別碼方法登錄。全部權(quán)限集用戶,可使用用戶登錄名+數(shù)字證書+動態(tài)密碼+數(shù)圖形識別碼方法登錄。應用系統(tǒng)可提供用戶端加密控件對用戶輸入密碼域進行加密處理后再提交。連續(xù)登錄數(shù)次失敗用戶,其IP將被應用系統(tǒng)鎖定,二十四小時后系統(tǒng)將自動對鎖定IP進行解鎖。這里登錄失敗次數(shù)和IP鎖定時長依據(jù)業(yè)務需求說明應由配置文件進行設定。對于首次登錄系統(tǒng)用戶,系統(tǒng)將強制訂位到修改密碼頁面,要求用戶修改初始密碼重新登錄方可使用系統(tǒng)。對于密碼類型和長度,系統(tǒng)將規(guī)則檢驗。對于成功登錄用戶,應用系統(tǒng)自動清除其連續(xù)登錄失敗次數(shù),同時初始化用戶相關(guān)數(shù)據(jù)并同時對登錄數(shù)據(jù)進行統(tǒng)計,以備審計。2.3.2會話控制需求經(jīng)過應用服務器本身會話管理或應用程序會話管理全部能夠控制會話時長設定,設置過久會話將給用戶端帶來安全風險,而設置過短則影響用戶正常使用。該機制使在應用層無狀態(tài)HTTP/HTTPS協(xié)議,能夠支持需要狀態(tài)統(tǒng)計互聯(lián)網(wǎng)應用,實現(xiàn)用戶登錄后在新狀態(tài)下從事交易、超時斷路等功效。2.3.3被訪問對象控制需求應用系統(tǒng)對用戶關(guān)鍵資源或信息,提供操作權(quán)限設置支持,權(quán)限分為:查詢和更新兩類。權(quán)限為查詢資源或信息只能對其進行查詢操作,不能進行更新。資源權(quán)限由開戶時指定,為加強安全性,權(quán)限分配可經(jīng)過落地處理開通。2.3.4交易提醒需求第三章應用系統(tǒng)安全總體處理方案3.1安全技術(shù)安全技術(shù)是安全子系統(tǒng)理論基礎,安全子系統(tǒng)中關(guān)鍵包含安全技術(shù)包含:密碼技術(shù)、PKI技術(shù)體系、一次性口令技術(shù)等,另外考慮到現(xiàn)在實際應用中,大部分WEB應用系統(tǒng)是基于J2EE平臺,J2EE平臺本身也對系統(tǒng)安全提供了較多內(nèi)置支持,如JAAS技術(shù)等,所以本章中對于J2EE平臺安全技術(shù)特征也有少許討論。3.1.1密碼技術(shù)密碼技術(shù)是保護信息系統(tǒng)安全基礎技術(shù)之一,密碼技術(shù)能夠確保數(shù)據(jù)保密性和完整性,同時它還含有身份認證和數(shù)字署名功效。從密碼體制方面來說,密碼技術(shù)可分為對稱密鑰密碼技術(shù)和非對稱密鑰密碼技術(shù)兩大類。在應用系統(tǒng)中常見密碼技術(shù)關(guān)鍵有以下多個:A.加密解密技術(shù)加密(Encryption)就是指經(jīng)過特定加密算法對數(shù)據(jù)進行變換,將明文(Plaintext)轉(zhuǎn)換成密文(Cryptograph);解密(Decryption)是加密逆過程,解密過程就是將密文還原為明文。設明文為P,密文為C,E為加密算法,D為解密算法,則加密解密過程能夠記為: (3.1)上述加密和解密過程沒有使用到密鑰,通常稱之為無密鑰密碼體制。無密鑰密碼關(guān)鍵依靠加密算法提供保密性,在應用系統(tǒng)中這種密碼極少用到,關(guān)鍵使用還是有密鑰密碼體制,在有密鑰密碼體制中,密文保密性依靠于密鑰而不依靠于算法,算法能夠公開。其中,只有一個密鑰K密碼體制稱為單鑰體制(One-keySystem),又稱對稱加密體制(SymmetricalEncryption);有加密密鑰KE和解密密鑰KD兩個密鑰密碼體制稱為雙鑰體制(Two-keySystem),又稱非對稱加密體制(DissymmetricalEncryption),有時也叫公開密鑰算法(PublicKeyAlgorithm)。應用系統(tǒng)中常常使用最廣泛對稱加密算法是DES算法(DataEncryptionStandard),非對稱加密算法是RSA算法(Receive,Shamir,Adelman)。單鑰體制加密解密過程能夠記為: (3.2)上式用圖示能夠表示為:明文明文密文明文加密密鑰K解密密鑰K圖5單鑰體制加密解密過程圖雙鑰體制加密解密過程能夠記為: (3.3)上式用圖示能夠表示為:明文明文密文明文加密密鑰KE解密密鑰KD圖6雙鑰體制加密解密過程圖還有一個應用系統(tǒng)中常常見到加密技術(shù)是數(shù)據(jù)摘要,數(shù)據(jù)摘要就是應用單向散列函數(shù)算法,將輸入任意長度明文變換成固定長度密文,而將此密文再轉(zhuǎn)換成明文在數(shù)學上來說是困難。應用系統(tǒng)中應用最廣泛數(shù)據(jù)摘要算法關(guān)鍵有MD5和SHA兩種,MD5輸出壓縮值為128bits,SHA輸出壓縮值為160bits。設Hash表示單向散列函數(shù),則數(shù)據(jù)摘要過程能夠記為: (3.4)上式用圖示能夠表示為:明文密文明文密文明文加密密鑰K解密密鑰K密文明文Hash圖7數(shù)據(jù)摘要過程圖B.數(shù)字署名。數(shù)字署名是指經(jīng)過密碼算法對原始數(shù)據(jù)信息進行加密處理后,生成一段原始數(shù)據(jù)信息信息標識,這段信息標識稱為原始數(shù)據(jù)信息數(shù)字署名。通常數(shù)字署名和原始數(shù)據(jù)信息是放在一起發(fā)送,這么便于信息接收者對其進行驗證,數(shù)字署名是對現(xiàn)實中手寫署名和印章模擬,數(shù)字署名只有信息發(fā)送方一人能產(chǎn)生,這種唯一性對應了原始數(shù)據(jù)信息起源。數(shù)字署名含有驗證數(shù)據(jù)完整性和信息起源不可否認性功效,這正是PKI體系提供關(guān)鍵功效。在應用系統(tǒng)中,較小數(shù)據(jù)能夠直接署名,而較大數(shù)據(jù)或文件通常先對其作數(shù)據(jù)摘要后再對數(shù)據(jù)摘要作數(shù)字署名。下式表示了對一段原始數(shù)據(jù)信息進行署名過程:原始數(shù)據(jù)信息OriginalMsg先是被單向散列函數(shù)Hash作數(shù)據(jù)摘要生成摘要信息DigestMsg,然后應用非對稱加密算法DissymmetricalEncrypt及其私鑰Keyprivate對數(shù)據(jù)摘要進行署名(私鑰僅有發(fā)送方持有,公鑰需散發(fā)給接收方),最終將署名結(jié)果DigitalSignature和原始數(shù)據(jù)信息一起發(fā)送給接收方:(3.4) 上式用圖示能夠表示為:OriginalMsgOriginalMsgKeyprivavteDigitalSignatureHashDissymmetricalEncrytDigestOriginalMsg+DigitalSignature圖8數(shù)字署名過程圖信息接收方在接收到原始數(shù)據(jù)信息OriginalMsg和其數(shù)字署名DigitalSignature后,能夠?qū)?shù)字署名進行驗證。首先分離出二者,然后對原始數(shù)據(jù)信息應用一樣單向散列函數(shù)Hash對其作數(shù)據(jù)摘要得到Digest2,再對接收到數(shù)字署名應用非對稱加密算法DissymmetricalEncrypt及其公鑰Keypublic對其進行解密,得到Digest1。比較Digest1和Digest2,假如二者一樣則證實:1.信息OriginalMsg及其數(shù)字署名DigitalSignature是真實,確實來自于私鑰Keyprivate持有方。2.信息OriginalMsg及其數(shù)字署名DigitalSignature在發(fā)送過程中是完整,未曾遭到篡改。3.私鑰Keyprivate持有方發(fā)送了信息OriginalMsg及其數(shù)字署名DigitalSignature這件事是不可否認。上述數(shù)字署名驗證過程能夠表示為:(3.5)用圖形表示以下:KeyKeypublicOriginalMsgDigitalSignatureHashDissymmetricalEncrytDigest2OriginalMsg+DigitalSignatureDigest2二者相同?圖9數(shù)字署名驗證過程圖C.報文識別碼應用系統(tǒng)跟其它系統(tǒng)通訊時大全部是經(jīng)過發(fā)送接收報文方法進行,除比較常見ISO8583,sop報文等,還有比較多就是自定義報文格式,自定義報文需要處理報文保密性和完整性問題,報文完整性能夠經(jīng)過加密算法生成原始報文報文標識來識別,這個加密后報文標識稱為原始報文識別碼,也叫報文校驗碼MAC(MessageAuthenticationCode)。而報文保密性能夠經(jīng)過對整個報文及其識別碼進行加密處理來完成,實際應用中識別碼通常能夠經(jīng)過單向散列函數(shù)對原始報文作數(shù)據(jù)摘要得到,然后對原始報文和數(shù)據(jù)摘要作對稱加密,這么既確保了報文完整性,同時也確保了報文保密性,這里對稱加密算法密鑰分發(fā)是關(guān)鍵問題。D.數(shù)字信封數(shù)字信封DE(DigitalEnvelope)是指信息發(fā)送方在通訊雙發(fā)首次通訊時,使用對方公鑰對雙方通訊密鑰SK(SymmentricKey)進行加密,形成一個數(shù)字信封,然后發(fā)給接收方,接收方收到數(shù)字信封后進行拆封操作,用自己私鑰對信封進行解密得到通訊密鑰,然后雙方能夠用通訊密鑰對自己發(fā)送信息進行對稱加密。這么既處理了對稱加密密鑰分配問題又提升了雙方通訊加密效率,畢竟非對稱加密算法比對稱加密算法效率要低下。3.1.2PKI體系PKI體系是由政策機構(gòu)、認證機構(gòu)和注冊機構(gòu)組成,經(jīng)過使用單向散列函數(shù)、非對稱加密體制等加密解密技術(shù),安全套接字協(xié)議SSL,LDAP協(xié)議(LightweightDirectoryAccessProtocol),X.509證書標準等技術(shù),實現(xiàn)數(shù)據(jù)加密、身份認證和數(shù)字署名等功效,從而確保數(shù)據(jù)保密性、完整性、真實性和不可否認性一個技術(shù)體系。PKI體系很好處理了網(wǎng)上銀行大部分安全需求,對網(wǎng)上銀行數(shù)據(jù)安全和業(yè)務邏輯安全提供了有力支持。CA是PKI體系關(guān)鍵實體,數(shù)字證書是CA關(guān)鍵產(chǎn)品,CA經(jīng)過數(shù)字證書應用來實現(xiàn)PKI體系所提供功效。1.PKI組成PKI由政策同意機構(gòu)PAA、政策CA機構(gòu)PCA、認證機構(gòu)CA和注冊機構(gòu)RA組成。PAA創(chuàng)建整個PKI系統(tǒng)方針、政策,同意本PAA下屬PCA政策,為下屬PCA簽發(fā)公鑰證書,建立整個PKI體系安全策略,并含有監(jiān)控個PCA行為責任[]。PCA制訂本身具體政策,包含密鑰產(chǎn)生、密鑰長度、證書使用期要求及CRL處理等,同時PCA為其下屬CA簽發(fā)公鑰證書。CA根據(jù)上級PCA制訂政策,為具體用戶簽發(fā)、生成并公布數(shù)字證書,負責CRL管理和維護。RA負責接收用戶證書申請,驗證用戶身份,向CA提交證書申請,驗證接收CA簽發(fā)數(shù)字證書,并將證書發(fā)放給申請者。PKI組成圖示以下:PCA1PCA1RA1PAAPCAnRAnCAnRAnRA1CAnCA1CA1圖10PKI體系結(jié)構(gòu)圖2.PKI操作功效證書生成及分發(fā)。在用戶向RA提交數(shù)字證書申請后,RA負責對申請者身份進行認證,認證經(jīng)過后RA將向CA轉(zhuǎn)發(fā)證書申請。CA負責生成用戶數(shù)字證書,數(shù)字證書公私密鑰對能夠由用戶產(chǎn)生,也能夠由CA產(chǎn)生。用戶自己產(chǎn)生公鑰需提交給CA,CA對公鑰強度驗證后將依據(jù)用戶提交公鑰產(chǎn)生用戶數(shù)字證書;假如是CA產(chǎn)生用戶公私密鑰對,則CA不保留用戶私鑰,私鑰需經(jīng)過安全方法發(fā)放給用戶。CA生成證書后將其公布到對應目錄服務器上。證書獲取。在PKI體系中,要獲取某個用戶數(shù)字證書,能夠RA處取得,也能夠查詢CA證書目錄服務器,另外用戶也能夠?qū)⒆约鹤C書發(fā)送給她人。證書廢止。數(shù)字證書廢止列表CRL獲取和查詢。因為CRL通常全部比較大,在線查詢效率比較低下,所以現(xiàn)在通常在RA端建立一個CRL鏡像,定時將CA端CRL同時到當?shù)兀瑫r又分全部CRL同時和增量同時兩種,全部CRL同時好處能確保CRL數(shù)據(jù)一致,缺點是同時數(shù)據(jù)量龐大,通常也沒有必需進行全局同時。增量同時就是每次只同時CA端新增CRL部分,增量同時數(shù)據(jù)量較小,比較符合現(xiàn)實。CRL查詢能夠經(jīng)過LDAP等訪問。證書恢復。證書恢復功效為用戶在證書存放介質(zhì)損壞或遺忘口令等情況下,提供原證書恢復,申請者向RA或CA提出證書恢復請求,CA將會為用戶生成新數(shù)字證書,原來證書將作廢,同時還會將其加入CRL中。證書更新。證書更新用于處理用戶證書到期后續(xù)費問題,也有可能是用戶證書并未抵達使用期而是CA或RA本身數(shù)字證書抵達了使用期。這時用戶需更新證書,CA將會為用戶簽發(fā)新數(shù)字證書。3.PKI服務功效PKI提供服務功效包含:數(shù)據(jù)保密性服務、數(shù)據(jù)完整性服務、數(shù)據(jù)真實性服務、數(shù)據(jù)不可否認性服務和身份認證服務。這些服務全部是經(jīng)過數(shù)字證書應用來實現(xiàn),在集成這些服務時,還需要應用系統(tǒng)作部分支持才能真正實現(xiàn)這些服務。3.1.3一次性口令技術(shù)所謂一次性口令(OTP,OneTimePassword)是指針對傳統(tǒng)可反復使用口令而言。一次性口令只能使用一次,不可反復使用。可重用口令易受種種攻擊:截取攻擊:當口令以明文方法在網(wǎng)絡上傳輸時,輕易被攻擊者截取取得,一旦口令泄漏則可能被未授權(quán)者非法使用。重放攻擊:當口令以密文方法在網(wǎng)絡上傳輸時,即使攻擊者無法獲取口令明文,但攻擊者能夠截取口令密文后對系統(tǒng)實施重放攻擊。窮舉攻擊:攻擊者還有可能針對用戶登錄名,依據(jù)系統(tǒng)對口令限定規(guī)則,嘗試規(guī)則范圍內(nèi)各個可能口令,對用戶口令實施窮舉攻擊。窺探:用戶在輸入可反復使用口令時肯定要借助某種輸入設備,如鍵盤、鼠標、手寫筆等,這時輕易被她人或其它錄影設備窺探到輸入內(nèi)容,也有可能被木馬程序等統(tǒng)計了擊鍵事件而分析出口令。社交工程:攻擊者經(jīng)過利用大家心理弱點、本能反應、好奇心、信任、貪婪等心理陷阱經(jīng)過電子郵件、電話訪談、釣魚網(wǎng)站等騙取用戶口令。垃圾搜索:攻擊者偽裝成垃圾工人搜集用戶垃圾文檔用以分析用戶口令等。一次口令因為每次使用各不相同口令,所以并不存在上述問題。一次口令并不要求用戶記住多個口令,所以也不會增加用戶和系統(tǒng)負擔。一次性口令原理:在用戶端和服務器端各存在一個相同算法、一個和用戶相關(guān)種子、一個不確定因子,每次系統(tǒng)對用戶進行認證時,用戶將不確定因子追加到種子后,然后用算法對其加密算出一個結(jié)果,這個結(jié)果作為一個一次性口令提交給服務器,服務器端用相同算法對相同種子和不確定因子進行運算,將得出結(jié)果和用戶提交結(jié)果進行比較,相同則說明用戶輸入口令是正確。一次性口令技術(shù)要求服務器端含有和用戶端相同算法、種子及不確定因子。這里關(guān)鍵是怎樣確保用戶端、服務器端含有相同不確定因子。兩端不確定因子選擇方法關(guān)鍵有以下三種:1.挑戰(zhàn)應答方法。每次用戶請求登錄系統(tǒng)時,服務器端將不確定因子發(fā)送給用戶,稱為一次挑戰(zhàn),而用戶提交口令是依據(jù)發(fā)送來不確定因子,和用戶端保留種子,由用戶端保留算法計算出來,所以每次計算出口令不相同。這里算法能夠采取單向散列函數(shù)算法,也能夠采取對稱加密算法。不確定因子采取挑戰(zhàn)應答方法原理能夠圖示以下:返回登錄結(jié)果返回登錄結(jié)果利用算法對種子和因子進行運算得出登錄口令并提交發(fā)送不確定因子請求登錄,輸入用戶名用戶系統(tǒng)圖11一次性口令應用原理圖2.時間同時方法。用戶端和服務器端以時間作為不確定因子,這里要求雙方時間是嚴格同時,正確度能夠控制在約定范圍內(nèi),比如說雙方時間差不超出一分鐘。3.事件同時方法。用戶端和服務器端以單向序列迭代值作為不確定因子,這里要求雙方每次迭代值大小相同。這種方法實現(xiàn)代價比時間同時方法小得多,而且也不用向挑戰(zhàn)應答方法那樣多出個挑戰(zhàn)交互,這種方法用戶端以單向迭代作為挑戰(zhàn),迭代作為規(guī)則能夠在用戶端實現(xiàn)。3.1.3基于J2EE平臺相關(guān)安全技術(shù)1.語言內(nèi)置安全技術(shù)Java語言含有強類型檢驗,在編譯時就能對變量類型進行檢驗;自動內(nèi)存管理,在C、C++中內(nèi)存分配和回收全部需要程序員負責完成,在大型應用中內(nèi)存泄漏是個頗為棘手問題,而Java內(nèi)置垃圾回收機制,由系統(tǒng)負責內(nèi)存管理;字節(jié)碼檢驗,JVM(JavaVirtualMachine)對源代碼編譯生成字節(jié)碼進行檢驗,預防惡意代碼對運行環(huán)境破壞;安全類裝載機制,確保不信任代碼不會影響其它Java程序運行。2.密碼技術(shù)支持JCA(JavaCryptographyArchitecture)和JCE(JavaCryptographicExtension)為加密、解密、數(shù)字證書、數(shù)據(jù)摘要提供完整支持;提供對多種密碼算法支持,包含RSA、DSA、DES、SHA等;提供對PKCS#11支持。3.認證和訪問控制支持JAAS(JavaAuthenticationandAuthorizationService)和Policy實現(xiàn)及語法等提供了細粒度訪問控制,抽象認證APIs能夠插件方法靈活地集成到其它登錄控制系統(tǒng)中。4.安全通訊JavaSecureSocketExtension(JSSE),JavaGSS-API(JGSS),JavaSimpleAuthenticationandSecurityLayerAPI(SASL)等提供對TransportLayerSecurity(TLS)、SSL、Kerberos、SASL等協(xié)議實現(xiàn),提供對基于SSL/TLSHTTPS完全支持,為數(shù)據(jù)完整性、保密性提供支持確保通訊安全。5.為PKI提供支持J2EE提供管理密鑰和證書工具,廣泛抽象APIs對X.509證書、廢止列表、證書路徑、OCSP(On-LineCertificateStatusProtocol)、PKCS#11、PKCS#12、LDAP等提供支持,大大簡化了PKI應用開發(fā)和布署難度[3]。3.2網(wǎng)絡總體結(jié)構(gòu)應用系統(tǒng)總體拓撲圖參考以下示:圖12應用系統(tǒng)總體拓撲圖參考用戶經(jīng)過Internet網(wǎng)絡向應用系統(tǒng)提議請求,請求在抵達Web服務器之前將經(jīng)過NSAE(使用兩臺帶SSL加速卡SSL安全網(wǎng)關(guān)服務器,并配置為熱備布署模式)建立128位SSL加密通信通道。系統(tǒng)應用服務器經(jīng)過有NSAE經(jīng)由Web服務器傳過來Request對象獲取用戶端證書(假如用戶端采取數(shù)字證書認證話)。在登錄步驟,系統(tǒng)應用服務器經(jīng)過身份認證及署名驗證服務器(NetSignServer)所提供API驗證用戶證書有效性并完成登錄。在交易過程中需要對交易署名時,經(jīng)過用戶端署名控件對頁面信息進行署名,署名結(jié)果信息及原始信息傳輸至應用服務器后,經(jīng)過署名驗證服務器(NetSignServer)提供API將署名結(jié)果和原始信息和用戶端證書傳至署名驗證服務器進行驗證。一次性口令驗證由系統(tǒng)應用程序調(diào)用動態(tài)密碼系統(tǒng)服務適配器,由動態(tài)密碼服務器完成驗證并返回結(jié)果。短信密碼發(fā)送,由動態(tài)密碼服務器向短信網(wǎng)關(guān)SMSGateway發(fā)送請求實現(xiàn)。3.3網(wǎng)絡層方案選擇3.3.1安全連接協(xié)議系統(tǒng)用戶端至服務器端安全連接常見協(xié)議有SSL、SPKM可供選擇[4]。SPKM(SimplePublicKeyMechanism)協(xié)議,用于建立點對點之間安全通道,結(jié)合數(shù)字證書關(guān)鍵適適用于內(nèi)聯(lián)網(wǎng)環(huán)境,在利用于互聯(lián)網(wǎng)時有以下問題[5]:1.因用戶端在跟服務器端建立連接時需要訪問CRL,而SPKM協(xié)議固有原因會造成用戶端對廢止列表訪問時間過長。2.SPKM協(xié)議在用戶端對整個頁面進行數(shù)字署名也是沒有必需,并不是用戶提交全部頁面全部需要數(shù)字署名,而且就算某個頁面需要數(shù)字署名通常也不是頁面中全部元素全部是需要數(shù)字署名。比如對于行外轉(zhuǎn)賬交易而言,收款人姓名、收款人賬號、收款人開戶行、轉(zhuǎn)賬金額、付款人賬號是其五要素,用戶在提交轉(zhuǎn)賬交易時只需對這五要素進行數(shù)字署名就能夠了,而頁面上還有部分諸如是否發(fā)送Email通知等要素就沒必再被署名了。超出需求要素被署名,首先將會增加網(wǎng)絡流量,同時還會造成服務器對應遲滯。3.因為SPKM協(xié)議并非普遍采取安全通訊協(xié)議,所以在通用瀏覽器如IE、Navigator等中沒有支持,需要下載安裝用戶端軟件,這就增加了系統(tǒng)安裝、維護、使用難度。SSL(SecuritySocketLayer)協(xié)議已得到各主流瀏覽器內(nèi)置支持。因為標準SSL協(xié)議,在采取用戶端證書時,并未對用戶交易數(shù)據(jù)進行顯式署名,造成應用系統(tǒng)無法統(tǒng)計交易數(shù)據(jù)數(shù)字署名,給在技術(shù)層面維護交易不可否認性帶來了一定困難[6]。在應用系統(tǒng)中我們采取SSL協(xié)議來建立安全連接。SSL協(xié)議署名問題可經(jīng)過在用戶瀏覽器端安裝署名控件來完成,署名控件首先能夠完成數(shù)字署名,其次,經(jīng)過自定義署名格式,只對需要頁面要素進行署名,去除無須要數(shù)據(jù)被署名。3.3.2安全區(qū)域劃分經(jīng)過三臺防火墻將網(wǎng)絡劃分為四個邏輯區(qū)域,按由外到內(nèi)次序布署。第一道防火墻之外是Internet區(qū)(非授信區(qū));第一道防火墻和第二道防火墻之間是Web區(qū),在此區(qū)域中布署SSL服務器和應用系統(tǒng)和網(wǎng)站系統(tǒng)Web服務器等其它第三方應用系統(tǒng);第二道防火墻和第三道防火墻之間是系統(tǒng)及網(wǎng)站應用/DB區(qū),在此區(qū)域中布署應用服務器和數(shù)據(jù)庫服務器;第三道防火墻以后為其它關(guān)鍵系統(tǒng)、中間業(yè)務平臺等第三方業(yè)務系統(tǒng)。3.3.2網(wǎng)絡層安全組件應用系統(tǒng)最外端布署了綠盟黑洞抗DoS攻擊系統(tǒng)COLLAPSAR600D-5-B,以控制拒絕式攻擊和分布式拒絕攻擊;防火墻采取是天融信防火墻產(chǎn)品NGFW4000-G,入侵檢測則采取是啟明入侵檢測NS500系統(tǒng),漏洞掃描軟件采取是冠群金辰承影網(wǎng)絡漏洞掃描器,原有系統(tǒng)被兩道防火墻分隔成三個區(qū)。系統(tǒng)布署時要求在?;饏^(qū)中再增加一道防火墻,首先隔離Web服務器和應用服務器;其次隔離應用服務器和其它關(guān)鍵系統(tǒng)。增加防火墻仍然采取是天融信NGFW4000-G防火墻,另外還增加了兩臺IBMTotalStorageSAN16M-2交換機,一套啟明NS500系統(tǒng)。3.4系統(tǒng)層方案選擇系統(tǒng)Web服務器操作系統(tǒng)采取SUSELinux9Enterprise,應用服務器和數(shù)據(jù)庫服務器操作系統(tǒng)采取AIX5L,V5.3,數(shù)據(jù)庫管理系統(tǒng)采取Oracle10.0.2FORAIX。因為軟件系統(tǒng)通常全部存在漏洞,操作系統(tǒng)也不例外,不管是Unix、Linux還是Windows系統(tǒng)。操作系統(tǒng)要求定時安裝系統(tǒng)最新補丁,并定時對審計日志進行檢驗和備份。另外,UNIX、Linux、NT系統(tǒng)通常包含很多網(wǎng)絡服務應用程序,如FTP、Telnet等,有些無須要網(wǎng)絡服務程序必需禁用并關(guān)閉對應端口。3.5應用層方案選擇3.5.1數(shù)字證書國外比較著名數(shù)字證書有:Verisign、Etrust、Baltimore等;中國應用比較廣泛數(shù)字證書關(guān)鍵有中國金融認證中心CFCA數(shù)字證書、上海數(shù)字證書認證中心SHECA證書等;另外有些實體建設了自己CA,向本實體內(nèi)系統(tǒng)及其用戶發(fā)放數(shù)字證書。對比分析上述幾家認證中心數(shù)字證書優(yōu)缺點將有利于安全子系統(tǒng)數(shù)字證書選擇。下表是比較結(jié)果:表8認證中心比較表格方案優(yōu)點缺點CFCA良好公信力,是金融領(lǐng)域CA權(quán)威高級證書

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論