對(duì)網(wǎng)站系統(tǒng)安全的需求分析

本文從數(shù)據(jù)安全與業(yè)務(wù)邏輯安全兩個(gè)角度對(duì)應(yīng)用系統(tǒng)的安全進(jìn)行需求分析，

要緊包含保密性需求、完整性需求、可用性需求三部分；隨后對(duì)業(yè)務(wù)邏輯安全需

求進(jìn)行了分析，包含身份認(rèn)證、訪問操縱、交易重復(fù)提交操縱、異步交易處理、

交易數(shù)據(jù)不可否認(rèn)性、監(jiān)控與審計(jì)等兒個(gè)方面；最后還分析了系統(tǒng)中一些其它的

安全需求。

2.1數(shù)據(jù)安全需求

2.1.1數(shù)據(jù)保密性需求

數(shù)據(jù)保密性要求數(shù)據(jù)只能由授權(quán)實(shí)體存取與識(shí)別，防止非授權(quán)泄露。從目前

國(guó)內(nèi)應(yīng)用的安全案例統(tǒng)計(jì)數(shù)據(jù)來看，數(shù)據(jù)保密性是最易受到攻擊的一個(gè)方面，通

常表現(xiàn)為客戶端發(fā)生的數(shù)據(jù)泄密，包含用戶的基本信息、賬戶信息、登錄信息等

的泄露。在應(yīng)用系統(tǒng)中，數(shù)據(jù)保密性需求通常要緊表達(dá)在下列幾個(gè)方面：

A.客戶端與系統(tǒng)交互時(shí)輸入的各類密碼：包含系統(tǒng)登錄密碼、轉(zhuǎn)賬密碼、

憑證查詢密碼、憑證交易密碼等務(wù)必加密傳輸及存放，這些密碼在應(yīng)用系統(tǒng)中只

能以密文的方式存在，其明文形式能且只能由其合法主體能夠識(shí)別。

以網(wǎng)銀系統(tǒng)為例，在網(wǎng)銀系統(tǒng)中，通常存有四種密碼：系統(tǒng)登錄密碼、網(wǎng)銀

轉(zhuǎn)賬密碼、柜面交易密碼及一次性密碼。系統(tǒng)登錄密碼用來認(rèn)證當(dāng)前登錄者為指

定登錄名的合法用戶，網(wǎng)銀用戶的登錄密碼與網(wǎng)銀轉(zhuǎn)賬密碼由用戶在柜面開戶時(shí)

指定，用戶在首次登錄網(wǎng)銀系統(tǒng)時(shí)，系統(tǒng)務(wù)必強(qiáng)制用戶修改初始密碼，通常要求

長(zhǎng)度不得少于六位數(shù)，且不能是類似于111111、1234567、9876543等的簡(jiǎn)單數(shù)

字序列，系統(tǒng)將進(jìn)行檢查。

網(wǎng)銀轉(zhuǎn)賬密碼是指網(wǎng)銀系統(tǒng)為鞏固用戶資金安全，在涉及資金變動(dòng)的交易中

對(duì)用戶身份進(jìn)行了再認(rèn)證，要求用戶輸入預(yù)設(shè)的密碼，網(wǎng)銀交易密碼僅針對(duì)個(gè)人

用戶使用，企業(yè)用戶沒有網(wǎng)銀交易密碼。建立多重密碼機(jī)制，將登錄密碼與網(wǎng)銀

轉(zhuǎn)賬密碼分開管理，有利于加強(qiáng)密碼的安全性。由于用戶在使用網(wǎng)銀時(shí)每次都務(wù)

必先提供登錄密碼，故登錄密碼暴露的機(jī)會(huì)較多，安全性相對(duì)較弱；但登錄網(wǎng)銀

的用戶并不是每次都會(huì)操作賬戶資金的，因此專門設(shè)定網(wǎng)銀轉(zhuǎn)賬密碼可加強(qiáng)賬戶

的安全性。網(wǎng)銀轉(zhuǎn)賬密碼在網(wǎng)銀開戶時(shí)設(shè)定，網(wǎng)銀用戶在系統(tǒng)中作轉(zhuǎn)賬支付、理

財(cái)、代繳費(fèi)等資金變動(dòng)類交易時(shí)使用。

柜面交易密碼是指用戶在銀行柜面辦理儲(chǔ)蓄時(shí)，針對(duì)儲(chǔ)蓄憑證（如卡折、存

單等）而設(shè)的密碼。柜面交易密碼常用于POS系統(tǒng)支付時(shí)、ATM取款時(shí)、憑證

柜面取款時(shí)，柜面交易密碼一個(gè)明顯的特征是它目前只能是六位的數(shù)字，這是由

于目前柜面密碼輸入設(shè)備的限制而造成的。柜面交易密碼與上述的網(wǎng)銀轉(zhuǎn)賬密碼

的區(qū)別在于：網(wǎng)銀轉(zhuǎn)賬密碼與系統(tǒng)登錄密碼都產(chǎn)生于網(wǎng)銀系統(tǒng)，儲(chǔ)存在網(wǎng)銀系統(tǒng)

中，僅限網(wǎng)銀系統(tǒng)中認(rèn)證使用；而柜面交易密碼產(chǎn)生于銀行柜臺(tái)，能夠在外圍渠

道如ATM、電話銀行、自助終端上修改，它儲(chǔ)存在銀行核心系統(tǒng)中，供外圍各

個(gè)渠道系統(tǒng)共同使用。另外網(wǎng)銀轉(zhuǎn)賬密碼能夠有非數(shù)字字符構(gòu)成，而柜面交易密

碼只能是六位的數(shù)字。網(wǎng)銀中使用到柜面交易密碼的交易包含：網(wǎng)銀開戶、加掛

賬戶c

一次性密碼由用戶的智能卡、令牌卡產(chǎn)生，或者由動(dòng)態(tài)密碼系統(tǒng)產(chǎn)生通過短

信方式發(fā)送到用戶注冊(cè)的手機(jī)上。一次性密碼的作用與網(wǎng)銀轉(zhuǎn)賬密碼相同，適用

的場(chǎng)合也相同。一次性密碼在農(nóng)商行網(wǎng)銀系統(tǒng)中是可選的安全服務(wù)，用戶需到柜

面辦理開通手續(xù)才能使用，沒有開通一次性密碼服務(wù)的用戶務(wù)必設(shè)定網(wǎng)銀交易密

碼，開通一次性密碼服務(wù)的用戶則無需設(shè)定網(wǎng)銀交易密碼，要求網(wǎng)銀系統(tǒng)自動(dòng)推

斷并提示用戶在某個(gè)交易中是要輸入網(wǎng)銀交易密碼還是提示一次性密碼。

B.應(yīng)用系統(tǒng)與其它系統(tǒng)進(jìn)行數(shù)據(jù)交換時(shí)在特定安全需求下需進(jìn)行端對(duì)端的

加解密處理。這里的數(shù)據(jù)加密要緊是為了防止交易數(shù)據(jù)被銀行內(nèi)部人士截取利

用，具體通訊加密方案參照應(yīng)用系統(tǒng)的特定需求。

2.1.2數(shù)據(jù)完整性需求

數(shù)據(jù)完整性要求防止非授權(quán)實(shí)體對(duì)數(shù)據(jù)進(jìn)行非法修改。用戶在跟應(yīng)用系統(tǒng)進(jìn)

行交互時(shí)，其輸入設(shè)備如鍵盤、鼠標(biāo)等有可能被木馬程序偵聽，輸入的數(shù)據(jù)遭到

截取修改后被提交到應(yīng)用系統(tǒng)中，如原本用戶準(zhǔn)備向A賬戶轉(zhuǎn)一筆資金在交易

數(shù)據(jù)遭到修改后就被轉(zhuǎn)到B賬戶中了。同樣的威脅還存在于交易數(shù)據(jù)的傳輸過

程中，如在用戶向應(yīng)用系統(tǒng)提交的網(wǎng)絡(luò)傳輸過程中或者應(yīng)用系統(tǒng)跟第三方等其它

系統(tǒng)的通訊過程中，另外存儲(chǔ)在應(yīng)用系統(tǒng)數(shù)據(jù)庫中的數(shù)據(jù)也有可能遭到非法修

改，如SQL注入攻擊等。

2.1.3數(shù)據(jù)可用性需求

數(shù)據(jù)可用性要求數(shù)據(jù)關(guān)于授權(quán)實(shí)體是有效、可用的，保證授權(quán)實(shí)體對(duì)數(shù)據(jù)的

合法存取權(quán)利。

對(duì)數(shù)據(jù)可用性最典型的攻擊就是拒絕式攻擊（DoS）與分布式拒絕攻擊，兩

者都是通過大量并發(fā)的惡意請(qǐng)求來占用系統(tǒng)資源，致使合法用戶無法正常訪問目

標(biāo)系統(tǒng)，如SYNFlood攻擊等，將會(huì)直接導(dǎo)致其他用戶無法登錄系統(tǒng)。另外，應(yīng)

用登錄機(jī)器人對(duì)用戶的密碼進(jìn)行窮舉攻擊也會(huì)嚴(yán)重影響系統(tǒng)的可用性。

2.2業(yè)務(wù)邏輯安全需求

業(yè)務(wù)邏輯安全要緊是為了保護(hù)應(yīng)用系統(tǒng)的業(yè)務(wù)邏輯按照特定的規(guī)則與流程

被存取及處理。

2.2.1身■份認(rèn)證需求

身份認(rèn)證就是確定某個(gè)個(gè)體身份的過程。系統(tǒng)通過身份認(rèn)證過程以識(shí)別個(gè)體

的用戶身份，確保個(gè)體為所宣稱的身份。應(yīng)用系統(tǒng)中身份認(rèn)證可分為單向身份認(rèn)

證與雙向身份認(rèn)證，單向身份認(rèn)證是指應(yīng)用系統(tǒng)對(duì)用戶進(jìn)行認(rèn)證，而雙向身份認(rèn)

證則指應(yīng)用系統(tǒng)與用戶進(jìn)行互相認(rèn)證，雙向身份認(rèn)證可有效防止“網(wǎng)絡(luò)釣魚”等

假網(wǎng)站對(duì)真正系統(tǒng)的旨充。

應(yīng)用服務(wù)器使用數(shù)字證書，向客戶端提供身份認(rèn)證，數(shù)字證書要求由權(quán)威、

獨(dú)立、公正的第三方機(jī)構(gòu)頒發(fā)；系統(tǒng)為客戶端提供兩種可選身份認(rèn)證方案，服務(wù)

器端對(duì)客戶端進(jìn)行多重身份認(rèn)證，要求充分考慮到客戶端安全問題。將客戶端用

戶身份認(rèn)證與賬戶身份認(rèn)證分開進(jìn)行，在用戶登錄系統(tǒng)時(shí)，使用單點(diǎn)用戶身份認(rèn)

證，在用戶提交更新類、管理類交易請(qǐng)求時(shí)，再次對(duì)用戶的操作進(jìn)行認(rèn)證或者對(duì)

用戶身份進(jìn)行二次認(rèn)證，以確保用戶信息安全。

2.2.2訪問操縱需求

訪問操縱規(guī)定了主體對(duì)客體訪問的限制，并在身份識(shí)別的基礎(chǔ)上，根據(jù)身份

對(duì)提出資源訪問的請(qǐng)求加以操縱。訪問操縱是應(yīng)用系統(tǒng)中的核心安全策略，它的

要緊任務(wù)是保證應(yīng)用系統(tǒng)資源不被非法訪問。主體、客體與主體對(duì)客體操作的權(quán)

限構(gòu)成訪問操縱機(jī)制的三要素。訪問操縱策略能夠劃分為自主訪問操縱、強(qiáng)制訪

間操縱與基于角色的訪問操縱三種。

2.2.3交易重復(fù)提交操縱需求

交易重復(fù)提交就是同一個(gè)交易被多次提交給應(yīng)用系統(tǒng)。查詢類的交易被重復(fù)

提交將會(huì)無故占用更多的系統(tǒng)資源，而管理類或者金融類的交易被重復(fù)提交后，

后果則會(huì)嚴(yán)重的多，譬如一筆轉(zhuǎn)賬交易被提交兩次則將導(dǎo)致用戶的賬戶被轉(zhuǎn)出兩

筆相同額的資金，顯然用戶只想轉(zhuǎn)出一筆。交易被重復(fù)提交可能是無意的，也有

可能是有意的：

A.用戶的誤操作。在B/S結(jié)構(gòu)中，從客戶端來看，服務(wù)器端對(duì)客戶端的響

應(yīng)總有一定的延遲，這在某些交易處理上表達(dá)的更為明顯，特別是那些涉及多個(gè)

系統(tǒng)交互、遠(yuǎn)程訪問、數(shù)據(jù)庫全表掃描、頁面數(shù)據(jù)簽名等交易，這種延遲通常都

會(huì)在5至7秒以上。這時(shí)用戶有可能在頁面已提交的情況下，再次點(diǎn)擊了提交按

鈕，這時(shí)將會(huì)造成交易被重復(fù)提交。

R.被提交的交易數(shù)據(jù)有可能被拿來作重放攻擊.

應(yīng)用系統(tǒng)務(wù)必對(duì)管理類與金融類交易提交的次數(shù)進(jìn)行操縱，這種操縱即要有

效的杜絕用戶的誤操作，還不能影響用戶正常情況下對(duì)某個(gè)交易的多次提交。比

如說：當(dāng)某個(gè)用戶在10秒內(nèi)提交了兩筆相同的轉(zhuǎn)賬業(yè)務(wù)，則系統(tǒng)務(wù)必對(duì)此進(jìn)行

操縱；另一方面，當(dāng)用戶在第一筆轉(zhuǎn)賬業(yè)務(wù)完成后，再作另一筆數(shù)據(jù)相同的轉(zhuǎn)賬

時(shí)，則系統(tǒng)不能對(duì)此進(jìn)行誤操縱。這里推斷的根據(jù)就是交易重復(fù)提交的操縱因子

a,當(dāng)交易提交的間隔小于a時(shí)，系統(tǒng)認(rèn)為這是重復(fù)提交，提交間隔大于a的則

不作處理，操縱因子的大小由應(yīng)用系統(tǒng)業(yè)務(wù)人員決定，系統(tǒng)應(yīng)可對(duì)其進(jìn)行配置化

管理。

2.2.4異步交易處理需求

所謂異步交易就是指那些錄入與提交不是同時(shí)完成的交易，這里的同時(shí)是指

客戶端在錄入交易數(shù)據(jù)與提交交易的過程中，應(yīng)用系統(tǒng)服務(wù)器端并沒有對(duì)錄入的

數(shù)據(jù)進(jìn)行持久化儲(chǔ)存，而異步交易在系統(tǒng)處理過程中，錄入與提交時(shí)間上發(fā)生在

兩個(gè)相分離的階段，在兩階段之間，應(yīng)用系統(tǒng)對(duì)錄入的數(shù)據(jù)進(jìn)行了持久化儲(chǔ)存。

由于異步交易是被系統(tǒng)分兩階段受理的，這就涉及到下列三個(gè)方面的問題：

A.錄入與提交的關(guān)系管理。

B.如何保證提交的數(shù)據(jù)就是用戶當(dāng)初錄入的數(shù)據(jù)。

C.如何記錄交易在兩階段的日志狀態(tài)。

錄入與提交的關(guān)系定義不當(dāng)將會(huì)導(dǎo)致交易錄入與提交被同時(shí)完成而違反了

業(yè)務(wù)處理流程，錄入的數(shù)據(jù)被系統(tǒng)儲(chǔ)存后有可能遭到非法篡改，非異步交易執(zhí)行

后的日志狀態(tài)不可能被更新而異步交易在提交后日志狀態(tài)將會(huì)被更新。

應(yīng)用系統(tǒng)中需要定義成異步的交易通常有下列兩類：

令需要授權(quán)的交易。出于業(yè)務(wù)管理與業(yè)務(wù)安全方面的考慮，大部分管理類

與金融類的交易都需要通過一定的授權(quán)流程后方能被提交。

令部分定時(shí)交易，如預(yù)約轉(zhuǎn)賬等。預(yù)約一筆在周三轉(zhuǎn)賬的預(yù)約轉(zhuǎn)賬有可能

是周一被錄入的，用戶在錄入后，預(yù)約轉(zhuǎn)賬的數(shù)據(jù)將被網(wǎng)銀系統(tǒng)儲(chǔ)存直

到周三這筆轉(zhuǎn)賬才會(huì)真正發(fā)生。

應(yīng)用系統(tǒng)務(wù)必定義簡(jiǎn)單、清晰、易保護(hù)的錄入與提交關(guān)系模型，保證被儲(chǔ)存

的錄入數(shù)據(jù)不可能被非法篡改，同時(shí)要求異步交易的日志狀態(tài)是明確的，不應(yīng)出

現(xiàn)錄入與提交相矛盾的F1志狀態(tài).

2.2.5交易數(shù)據(jù)不可否認(rèn)性需求

交易數(shù)據(jù)不可否認(rèn)性是指應(yīng)用系統(tǒng)的客戶不能否認(rèn)其所簽名的數(shù)據(jù)，客戶對(duì)

交易數(shù)據(jù)的簽名是通過應(yīng)用系統(tǒng)使用客戶的數(shù)字證書來完成的。數(shù)字證書的應(yīng)用

為交易數(shù)據(jù)不可否認(rèn)性提供了技術(shù)支持，而電子簽名法的頒布為交易數(shù)據(jù)不可否

認(rèn)性提供了法律基礎(chǔ)。

在應(yīng)用系統(tǒng)中通常要求對(duì)所有管理類與金融類的交易進(jìn)行數(shù)字簽名，以防客

戶事后對(duì)交易或者交易數(shù)據(jù)的抵賴。應(yīng)用系統(tǒng)需同時(shí)儲(chǔ)存客戶錄入的原始數(shù)據(jù)與

簽名后的數(shù)據(jù)，儲(chǔ)存期限依業(yè)務(wù)部門的具體要求而定?？紤]到系統(tǒng)性能與對(duì)用戶

的響應(yīng)問題，應(yīng)用系統(tǒng)可只簽與交易有關(guān)的關(guān)鍵數(shù)據(jù)，支付類的交易只應(yīng)付款人

賬號(hào)、付款金額、收款人姓名、收款人賬號(hào)、收款人開戶行五個(gè)字段進(jìn)行數(shù)字簽

名就能夠了。

2.2.6監(jiān)控與審計(jì)需求

安全級(jí)別要求高的應(yīng)用系統(tǒng)應(yīng)提供對(duì)系統(tǒng)進(jìn)行實(shí)時(shí)監(jiān)控的功能，監(jiān)控的內(nèi)容

包含系統(tǒng)當(dāng)前登錄的用戶、用戶類型、用戶正在訪問的交易、用戶登錄的IP等。

對(duì)金融類、管理類的交易與應(yīng)用系統(tǒng)登錄交易需要完整地記錄用戶的訪問過程，

記錄的關(guān)鍵元素包含：用戶登錄名、登錄IP、交易日期及時(shí)間、交易名稱、交

易有關(guān)數(shù)據(jù)等，對(duì)有授權(quán)流程的交易要求完整記錄授權(quán)的通過，授權(quán)記錄與交易

記錄分開存放。

2.3其它安全需求

2.3.1登錄操縱需求

登錄通常是應(yīng)用系統(tǒng)的關(guān)鍵交易，系統(tǒng)通過登錄交易對(duì)用戶身份進(jìn)行認(rèn)證。

針對(duì)不一致角色的用戶指定不一致的登錄策略：

令最小權(quán)限集用戶，可使用用戶登錄名+靜態(tài)登錄密碼+圖形識(shí)別碼方式登

錄。低安全性。

令普通權(quán)限集用戶，可使用用戶登錄名+動(dòng)態(tài)登錄密碼+數(shù)圖形識(shí)別碼方式

登錄。

。高權(quán)限集用戶，可使用用戶登錄名+數(shù)字證書+靜態(tài)密碼+數(shù)圖形識(shí)別碼

方式登錄.

令所有權(quán)限集用戶，可使用用戶登錄名+數(shù)字證書+動(dòng)態(tài)密碼+數(shù)圖形識(shí)別

碼方式登錄。

應(yīng)用系統(tǒng)可提供客戶端加密控件對(duì)用戶輸入的密碼域進(jìn)行加密處理后再提

交。

連續(xù)登錄多次失敗的用戶，其IP將被應(yīng)用系統(tǒng)鎖定，24小時(shí)后系統(tǒng)將自動(dòng)

對(duì)鎖定的IP進(jìn)行解鎖。這里登錄失敗的次數(shù)與IP鎖定時(shí)長(zhǎng)根據(jù)業(yè)務(wù)需求說明應(yīng)

由配置文件進(jìn)行設(shè)定。

關(guān)于首次登錄系統(tǒng)的用戶，系統(tǒng)將強(qiáng)制定位到修改密碼的頁面，要求用戶修

改初始密碼重新登錄方可使用系統(tǒng)。關(guān)于密碼類型與長(zhǎng)度，系統(tǒng)將規(guī)則檢查。

關(guān)于成功登錄的用戶，應(yīng)用系統(tǒng)自動(dòng)清除其連續(xù)登錄失敗的次數(shù)，同時(shí)初始

化用戶的有關(guān)數(shù)據(jù)并同時(shí)對(duì)登錄數(shù)據(jù)進(jìn)行記錄，以備審計(jì)工

2.3.2會(huì)話操縱需求

233被訪問對(duì)象操縱需求

應(yīng)用系統(tǒng)對(duì)用戶的關(guān)鍵資源或者信息，提供操作權(quán)限設(shè)置支持，權(quán)限分為：

查詢與更新兩類。權(quán)限為查詢的資源或者信息只能對(duì)其進(jìn)行查詢操作，不能進(jìn)行

更新。資源權(quán)限由開戶時(shí)指定，為加強(qiáng)安全性，雙限分配可通過落地處理開通。

2.3.4交易提醒需求

交易提醒是指將客戶的賬號(hào)與客戶手機(jī)號(hào)、電子郵件等關(guān)聯(lián)起來，當(dāng)客戶信息

發(fā)生變動(dòng)時(shí).，向客戶的手機(jī)發(fā)送一條短信或者電話通知或者發(fā)送一封電子郵件，及

時(shí)準(zhǔn)確的告知客戶。另通過通知提醒功能，系統(tǒng)應(yīng)定期向用戶發(fā)送統(tǒng)計(jì)、明細(xì)、確

認(rèn)等信息。

第三章應(yīng)用系統(tǒng)安全的總體解決方案

3.1安全技術(shù)

安全技術(shù)是安全子系統(tǒng)的理論基礎(chǔ)，安全子系統(tǒng)中要緊涉及的安全技術(shù)包

含：密碼技術(shù)、PKI技術(shù)體系、一次性口令技術(shù)等，另外考慮到目前實(shí)際應(yīng)用中,

大部分WEB應(yīng)用系統(tǒng)是基于J2EE平臺(tái)的，J2EE平臺(tái)本身也對(duì)系統(tǒng)安全提供了

較多內(nèi)置的支持，如JAAS技術(shù)等，因此本章中關(guān)于J2EE平臺(tái)的安全技術(shù)特性

也有少量的討論。

3.1.1密碼技術(shù)

密碼技術(shù)是保護(hù)信息系統(tǒng)安全的基礎(chǔ)技術(shù)之一，密碼技術(shù)能夠保證數(shù)據(jù)的保

密性與完整性，同時(shí)它還具有身份認(rèn)證與數(shù)字簽名的功能。從密碼體制方面來說,

密碼技術(shù)可分為對(duì)稱密鑰密碼技術(shù)與非對(duì)稱密鑰密碼技術(shù)兩大類。在應(yīng)用系統(tǒng)中

常用的密碼技術(shù)要緊有下列幾種：

A.加密解密技術(shù)

加密(Encryption)就是指通過特定的加密算法對(duì)數(shù)據(jù)進(jìn)行變換，將明文

(Plaintext)轉(zhuǎn)換成密文(Cryptograph)；解密(Decryption)是加密的逆過程,

解密的過程就是將密文還原為明文。設(shè)明文為P,密文為C,E為加密算法，D

為解密算法，則加密解密的過程能夠記為：

C=E(P)

(3.1)

P=D(C)

上述的加密與解密過程沒有使用到密鑰，通常稱之為無密鑰密碼體

制。無密鑰密碼要緊依靠加密算法提供保密性，在應(yīng)用系統(tǒng)中這種密碼

很少用到，要緊使用還是有密鑰的密碼體制，在有密鑰的密碼體制中，

密文的保密性依靠于密鑰而不依靠于算法，算法能夠公開。其中，只有

一個(gè)密鑰K的密碼體制稱之單鑰體制(One-keySystem),又稱對(duì)稱

加密體制(SymmetricalEncryption)；有加密密鑰KE與解密密鑰KD

兩個(gè)密鑰的密碼體制稱之雙鑰體制(Two-kcySystem),又稱非對(duì)稱加

密體制(DissymmetricalEncryption),有的時(shí)候也叫公開密鑰算法(P

ublicKeyAlgorithm)。應(yīng)用系統(tǒng)中經(jīng)常使用最廣泛的對(duì)稱加密算法是D

ES算法(DataEncryptionStandard),非對(duì)稱加密算法是RSA算法(R

eceive,Shamir,Adelman)?單鑰體制的加密解密過程能夠記為:

C=E(P,K)

(3.2)

P=D(C.K)

上式用圖示能夠表示為：

圖5單鑰體制加密解密過程圖

雙鑰體制的加密解密過程能夠記為：

C=E(P,KE)

P=D(C,KD)

上式用圖示能夠表示為：

圖6雙鑰體制加密解密過程圖

還有一種應(yīng)用系統(tǒng)中經(jīng)常用到的加密技術(shù)是數(shù)據(jù)摘要，數(shù)據(jù)摘要就

是應(yīng)用單向散列函數(shù)算法，將輸入的任意長(zhǎng)度明文變換成固定長(zhǎng)度的密

文，而將此密文再轉(zhuǎn)換成明文在數(shù)學(xué)上來說是困難的。應(yīng)用系統(tǒng)中應(yīng)用

最廣泛的數(shù)據(jù)摘要算法要緊有MD5與SHA兩種，MD5輸出壓縮值為

128bits,SHA輸出壓縮值為160bits。設(shè)Hash表示單向散列函數(shù),則數(shù)

據(jù)摘要的過程能夠記為：

C=Hash(P)(3.4)

上式用圖示能夠表示為:

明文、|--------密文

二^"Hash_

圖7數(shù)據(jù)摘要的過程圖

B.數(shù)字簽名。

數(shù)字簽名是指通過密碼算法對(duì)原始數(shù)據(jù)信息進(jìn)行加密處理后，生成一段原始

數(shù)據(jù)信息的信息標(biāo)識(shí)，這段信息標(biāo)識(shí)稱之原始數(shù)據(jù)信息的數(shù)字簽名。通常數(shù)字簽

名與原始數(shù)據(jù)信息是放在一起發(fā)送的，這樣便于信息的同意者對(duì)其進(jìn)行驗(yàn)證，數(shù)

字簽名是對(duì)現(xiàn)實(shí)中手寫簽名與印章的模擬，數(shù)字簽名只有信息發(fā)送方一人能產(chǎn)

生，這種唯一性對(duì)應(yīng)了原始數(shù)據(jù)信息的來源。數(shù)字簽名具有驗(yàn)證數(shù)據(jù)完整性與信

息來源不可否認(rèn)性的功能，這正是PKI體系提供的核心功能。

在應(yīng)用系統(tǒng)中，較小的數(shù)據(jù)能夠直接簽名，而較大的數(shù)據(jù)或者文件通常先對(duì)

其作數(shù)據(jù)摘要后再對(duì)數(shù)據(jù)摘要作數(shù)字簽名。下式表達(dá)了對(duì)一段原始數(shù)據(jù)信息進(jìn)行

簽名的過程：原始數(shù)據(jù)信息OriginalMsg先是被單向散列函數(shù)Hash作數(shù)據(jù)摘要

生成摘要信息DigestMsg,然后應(yīng)用非對(duì)稱加密算法DissymmelricalEncrypt及其

私鑰Keypriwe對(duì)數(shù)據(jù)摘要進(jìn)行簽名（私鑰僅有發(fā)送方持有，公鑰需散發(fā)給接收

方），最后將簽名結(jié)果DigitalSignature與原始數(shù)據(jù)信息一起發(fā)送給同意方：

DigestMsg=Hash(OriginalMsg)

DigitalSignature=DissymmetricaIEncrypt(DigestMsg,Keyprivate)

(3.4)

上式用圖示能夠表示為:

圖8數(shù)字簽名的過程圖

信息同意方在同意到原始數(shù)據(jù)信息OriginalMsg與其數(shù)字簽名

DigitalSignature后，能夠?qū)?shù)字簽名進(jìn)行驗(yàn)證。首先分離出兩者，然后對(duì)原始數(shù)

據(jù)信息應(yīng)用同樣的單向散列函數(shù)Hash對(duì)其作數(shù)據(jù)摘要得到Digest2,再對(duì)接收到

的數(shù)字簽名應(yīng)用非對(duì)稱加密算法DissymmetricalEncrypt及其公鑰KeypUbiic對(duì)其進(jìn)

行解密,得到Digest%比較Digestl與Digest2,假如兩者一樣則證明:

1.信息OriginalMsg及其數(shù)字簽名DigitalSignature是真實(shí)的,確實(shí)來自于

私鑰Keyprivaie的持有方。

2.信息OriginalMsg及其數(shù)字簽名DigitalSignature在發(fā)送過程中是完整的，

未曾遭到篡改。

3.私鑰Keyprivate的持有方發(fā)送了信息OriginalMsg及其數(shù)字簽名

DigitalSignature這件事是不可否認(rèn)的。

上述數(shù)字簽名的驗(yàn)證過程能夠表達(dá)為：

DigestMsg2=Hash(OriginalMs^)

DigeslMsgl=DissymmetricalEncry/)t(Di^italSiffiature,Keypublic)

DigestMsgl==DigestMsg]?

(3.5)

用圖形表示如下：

圖9數(shù)字簽名驗(yàn)證的過程圖

C.報(bào)文識(shí)別碼

應(yīng)用系統(tǒng)跟其它系統(tǒng)通訊時(shí)大都是通過發(fā)送接收?qǐng)?bào)文方式進(jìn)行的，除比較常

用的ISO8583,sop報(bào)文等，還有比較多的就是自定義的報(bào)文格式，自定義農(nóng)文

需要解決報(bào)文的保密性與完整性問題，報(bào)文的完整性能夠通過加密算法生成原始

報(bào)文的報(bào)文標(biāo)識(shí)來識(shí)別，這個(gè)加密后的報(bào)文標(biāo)識(shí)稱之原始報(bào)文的識(shí)別碼，也叫報(bào)

文校驗(yàn)碼MAC(MessageAuthenticationCode)。而報(bào)文的保密性能夠通過對(duì)整

個(gè)報(bào)文及其識(shí)別碼進(jìn)行加密處理來完成，實(shí)際應(yīng)用中識(shí)別碼通常能夠通過單向散

列函數(shù)對(duì)原始報(bào)文作數(shù)據(jù)摘要得到，然后對(duì)原始報(bào)文與數(shù)據(jù)摘要作對(duì)稱加密，這

樣既保證了報(bào)文的完整性，同時(shí)也保證了報(bào)文的保密性，這里對(duì)稱加密算法的密

鑰分發(fā)是要緊問題。

D.數(shù)字信封

數(shù)字信封DE(DigitalEnvelope)是指信息發(fā)送方在通訊雙發(fā)首次通訊時(shí)，

使用對(duì)方的公鑰對(duì)雙方的通訊密鑰SK(SymmentricKey)進(jìn)行加密，形成一個(gè)

數(shù)字信封，然后發(fā)給接收方，接收方收到數(shù)字信封后進(jìn)行拆封操作，用自己的私

鑰對(duì)信封進(jìn)行解密得到通訊密鑰，然后雙方能夠用通訊密鑰對(duì)自己發(fā)送的信息進(jìn)

行對(duì)稱加密⑷。這樣既解決了對(duì)稱加密的密鑰分配問題又提高了雙方通訊加密的

效率，畢竟非對(duì)稱加密算法比對(duì)稱加密算法效率要低下。

3.1.2PKI體系

PKI體系是由政策機(jī)構(gòu)、認(rèn)證機(jī)構(gòu)與注冊(cè)機(jī)構(gòu)構(gòu)成的，通過使用單向散列函

數(shù)、非對(duì)稱加密體制等加密解密技術(shù)，安全套接字協(xié)議SSL,LDAP協(xié)議

(LightweightDirectoryAccessProtocol),X.509證書標(biāo)準(zhǔn)等技術(shù),實(shí)現(xiàn)數(shù)據(jù)加

密、身份認(rèn)證與數(shù)字簽名等功能，從而保證數(shù)據(jù)保密性、完整性、真實(shí)性與不可

否認(rèn)性的一種技術(shù)體系。PKI體系很好的解決了網(wǎng)上銀行的大部分安全需求，對(duì)

網(wǎng)上銀行的數(shù)據(jù)安全與業(yè)務(wù)邏輯安全提供了有力的支持。CA是PKI體系的要緊

實(shí)體，數(shù)字證書是CA的要緊產(chǎn)品，CA通過數(shù)字證書的應(yīng)用來實(shí)現(xiàn)PKI體系所

提供的功能。

1.PKI的構(gòu)成

PKI由政策批準(zhǔn)機(jī)構(gòu)PAA、政策CA機(jī)構(gòu)PCA、認(rèn)證機(jī)構(gòu)CA與注冊(cè)機(jī)構(gòu)

RA構(gòu)成。PAA創(chuàng)建整個(gè)PKI系統(tǒng)的方針、政策，批準(zhǔn)本PAA下屬的PCA的政

策，為下屬PCA簽發(fā)公鑰證書，建立整個(gè)PKI體系的安全策略，并具有監(jiān)控個(gè)

PCA行為的責(zé)任U。PCA制定自身的具體政策，包含密鑰的產(chǎn)生、密鑰的長(zhǎng)度、

證書的有效期規(guī)定及CRL的處理等，同時(shí)PCA為其下屬CA簽發(fā)公鑰證書。CA

按照上級(jí)PCA制定的政策，為具體用戶簽發(fā)、生成并公布數(shù)字證書，負(fù)責(zé)CRL

的管理與保護(hù)。RA負(fù)責(zé)接收用戶的證書申請(qǐng)，驗(yàn)證用戶的身份，向CA提交證

書申請(qǐng)，驗(yàn)證接收CA簽發(fā)的數(shù)字證書，并將證書發(fā)放給申請(qǐng)者。PKI的構(gòu)成圖

示如下:

圖10PKI的體系結(jié)構(gòu)圖

2.PKI的操作功能

證書的生成及分發(fā)。在用戶向RA提交數(shù)字證書申請(qǐng)后，RA負(fù)責(zé)對(duì)申請(qǐng)者

的身份進(jìn)行認(rèn)證，認(rèn)證通過后RA將向CA轉(zhuǎn)發(fā)證書申請(qǐng)。CA負(fù)責(zé)生成用戶的

數(shù)字證書，數(shù)字證書的公私密鑰對(duì)能夠由用戶產(chǎn)生，也能夠由CA產(chǎn)生。用戶自

己產(chǎn)生的公鑰需提交給CA,CA對(duì)公鑰強(qiáng)度驗(yàn)證后將根據(jù)用戶提交的公鑰產(chǎn)生

用戶的數(shù)字證書；假如是CA產(chǎn)生用戶的公私密鑰對(duì)，則CA不儲(chǔ)存用戶的私鑰,

私鑰需通過安全的方式發(fā)放給用戶。CA生成證書后將其公布到相應(yīng)的目錄服務(wù)

器上。

證書的獲取。在PKI體系中，要獲取某個(gè)用戶的數(shù)字證書，能夠RA處獲得,

也能夠查詢CA的證書目錄服務(wù)器，另外用戶也能夠?qū)⒆约旱淖C書發(fā)送給另1人。

證書的廢止。數(shù)字證書的持證人假如發(fā)生證書丟失、密鑰泄漏時(shí)，持證人能夠

向CA或者RA提交證書廢止請(qǐng)求，CA將會(huì)把用戶的證書加入到廢止列表中。

廢止列表CRL的獲取與查詢。由于CRL通常都比較大，在線查詢效率比較

低下，因此現(xiàn)在通常在RA端建立一個(gè)CRL的鏡像，定期將CA端的CRL同步

到本地，同步又分全部CRL同步與增量同步兩種，全部CRL同步的好處能保證

CRL數(shù)據(jù)一致，缺點(diǎn)是同步的數(shù)據(jù)量龐大，通常也沒有必要進(jìn)行全局同步。增

量同步就是每次只同步CA端新增的CRL部分，增量同步的數(shù)據(jù)量較小，比較

符合現(xiàn)實(shí)。CRL的查詢能夠通過LDAP等訪問。

證書恢復(fù)。證書恢復(fù)功能為客戶在證書存儲(chǔ)介質(zhì)損壞或者遺忘口令等情況

下，提供原證書的恢復(fù)，申請(qǐng)者向RA或者CA提出證書恢復(fù)請(qǐng)求，CA將會(huì)為

用戶生成新的數(shù)字證書，原先的證書將作廢，同時(shí)還會(huì)將其加入CRL中。

證書更新。證書更新用于解決客戶證書到期后的續(xù)費(fèi)問題，也有可能是客戶

的證書并未到達(dá)有效期而是CA或者RA的本身的數(shù)字證書到達(dá)了有效期。這時(shí)

用戶需更新證書，CA將會(huì)為用戶簽發(fā)新的數(shù)字證書。

3.PKI的服務(wù)功能

PKI提供的服務(wù)功能包含：數(shù)據(jù)?？招苑?wù)、數(shù)據(jù)完整性服務(wù)、數(shù)據(jù)真實(shí)性

服務(wù)、數(shù)據(jù)不可否認(rèn)性服務(wù)與身份認(rèn)證服務(wù)。這些服務(wù)都是通過數(shù)字證書的應(yīng)用

來實(shí)現(xiàn)的，在集成這些服務(wù)時(shí)，還需要應(yīng)用系統(tǒng)作部分支持才能真正實(shí)現(xiàn)這些服

務(wù)。

3.1.3一次性口令技術(shù)

所謂一次性口令(OTP,OneTimePassword)是指針對(duì)傳統(tǒng)可重復(fù)使用的口

令而言的。一次性口令只能使用一次，不可重復(fù)使用?？芍赜玫目诹钜资芊N種攻

擊：

截取攻擊：當(dāng)口令以明文方式在網(wǎng)絡(luò)上傳遞時(shí)，容易被攻擊者截取獲得，一

旦口令泄漏則可能被未授權(quán)者非法使用。

重放攻擊：當(dāng)口令以密文方式在網(wǎng)絡(luò)上傳遞時(shí)，盡管攻擊者無法獲取口令的

明文，但攻擊者能夠截取口令密文后對(duì)系統(tǒng)實(shí)施重放攻擊。

窮舉攻擊:攻擊者還有可能針對(duì)用戶的登錄名，根據(jù)系統(tǒng)對(duì)口令的限定規(guī)則,

嘗試規(guī)則范圍內(nèi)各個(gè)可能的口令，對(duì)用戶口令實(shí)施窮舉攻擊。

窺探：用戶在輸入可重復(fù)使用的口令時(shí)必定要借助某種輸入設(shè)備，如鍵盤、

鼠標(biāo)、手寫筆等，這時(shí)容易被他人或者其它錄影設(shè)備窺探到輸入內(nèi)容，也有可能

被木馬程序等記錄了擊鍵事件而分析出口令。

社交工程：攻擊者通過利用人們心理弱點(diǎn)、本能反應(yīng)、好奇心、信任、貪婪

等心理陷阱通過電子郵件、電話訪談、釣魚網(wǎng)站等騙取用戶的口令。

垃圾搜索：攻擊者偽裝成垃圾工人收集用戶的垃圾文檔用以分析用戶的口令

等。

一次口令由于每次使用各不相同的口令，因此并不存在上述的問題。一次口

令并不要求用戶記住多個(gè)口令，因此也不可能增加用戶與系統(tǒng)的負(fù)擔(dān)。一次性口

令的原理:在客戶端與服務(wù)器端各存在一個(gè)相同的算法、一個(gè)與用戶有關(guān)的種子、

一個(gè)不確定的因子，每次系統(tǒng)對(duì)用戶進(jìn)行認(rèn)證時(shí)，用戶將不確定的因子追加到種

子后，然后用算法對(duì)其加密算出一個(gè)結(jié)果，這個(gè)垢果作為一個(gè)一次性口令提交給

服務(wù)器，服務(wù)器端用相同的算法對(duì)相同種子與不確定因子進(jìn)行運(yùn)算，將得出的結(jié)

果與用戶提交的結(jié)果進(jìn)行比較，相同則說明用戶輸入的口令是正確的。

一次性口令技術(shù)要求服務(wù)器端具有與用戶端相同的算法、種子及不確定因

子.這里關(guān)鍵是如何保證客戶端、服務(wù)器端具有相同的不確定因子C兩端不確定

因子的選擇方式要緊有下列三種：

I.挑戰(zhàn)應(yīng)答方式。每次用戶請(qǐng)求登錄系統(tǒng)時(shí)，服務(wù)器端將不確定因子發(fā)送

給用戶，稱之一次挑戰(zhàn)，而用戶提交的口令是根據(jù)發(fā)送來的不確定因子，與用戶

端儲(chǔ)存的種子，由用戶端儲(chǔ)存的算法計(jì)算出來的，因此每次計(jì)算出的口令不相同。

這里的算法能夠使用單向散列函數(shù)算法，也能夠使用對(duì)稱加密算法。不確定因子

使用挑戰(zhàn)應(yīng)答方式的原理能夠圖示如下：

請(qǐng)求登錄，輸入用戶名

發(fā)送不確定因子

用c------------------------------------系

運(yùn)用算法對(duì)種子與因子進(jìn)行

運(yùn)算得出登錄口令并提交

------------------------------------>

戶統(tǒng)

返回登錄結(jié)果

圖11一次性口令應(yīng)用的原理圖

2.時(shí)間同步方式?？蛻舳伺c服務(wù)器端以時(shí)間作為不確定因子，這

里要求雙方的時(shí)間是嚴(yán)格同步的，精確度能夠操縱在約定的范圍內(nèi)，比

如說雙方的時(shí)間差不超過一分鐘。

3.事件同步方式。客戶端與服務(wù)器端以單向序列的迭代值作為不

確定因子，這里要求雙方每次迭代值的大小相同。這種方式的實(shí)現(xiàn)代價(jià)

比時(shí)間同步方式的小得多，而且也不用向挑戰(zhàn)應(yīng)答方式那樣多出個(gè)挑戰(zhàn)

的交互，這種方式客戶端以單向迭代作為挑戰(zhàn)，迭代作為規(guī)則能夠在客

戶端實(shí)現(xiàn)。

3.1.3基于J2EE平臺(tái)的有關(guān)安全技術(shù)

1.語言內(nèi)置的安全技術(shù)

Java語言具有強(qiáng)類型檢查，在編譯時(shí)就能對(duì)變量類型進(jìn)行檢查；自動(dòng)內(nèi)存管

理，在C、C++中內(nèi)存的分配與回收都需要程序員負(fù)責(zé)完成，在大型應(yīng)用中內(nèi)存

泄漏是個(gè)頗為棘手的問題，而Java內(nèi)置垃圾回收機(jī)制，由系統(tǒng)負(fù)責(zé)內(nèi)存的管理;

字節(jié)碼檢查，JVM(JavaVirtualMachine)對(duì)源代碼編譯生成的字節(jié)碼進(jìn)行檢查,

防止惡意代碼對(duì)運(yùn)行環(huán)境的破壞；安全的類裝載機(jī)制，確保不信任的代碼不可能

影響其它Java程序的運(yùn)行。

2.密碼技術(shù)支持

JCA(JavaCryptographyArchitecture)與JCE(JavaCryptographicExtension)

為加密、解密、數(shù)字證書、數(shù)據(jù)摘要提供完整的支持；提供對(duì)各類密碼算法的支

持，包含RSA、DSA、DES、SHA等；提供對(duì)PKCS#11的支持。

3.認(rèn)證與訪問操縱支持

JAAS(JavaAuthenticationandAuthorizationService)與Policy的實(shí)現(xiàn)及語法

等提供了細(xì)粒度的訪問操縱，抽象的認(rèn)證APIs能夠插件方式靈活地集成到其它

登錄操縱系統(tǒng)中。

4.安全通訊

5.為PKI提供支持

J2EE提供管理密鑰與證書的工具，廣泛抽象的APIs對(duì)X.509證書、廢止列

表、證書路徑、OCSP(On-LineCertificateStotusProtocol)PKCS#lkPKCS#12>

LDAP等提供支持，大大簡(jiǎn)化了PKI應(yīng)用開發(fā)與部署的難度⑶。

3.2網(wǎng)絡(luò)總體結(jié)構(gòu)

應(yīng)用系統(tǒng)的總體拓?fù)鋱D參考如下示:

圖12應(yīng)用系統(tǒng)的總體拓?fù)鋱D參考

用戶通過Internet網(wǎng)絡(luò)向應(yīng)用系統(tǒng)發(fā)起請(qǐng)求，請(qǐng)求在到達(dá)Web服務(wù)器之前將

通過NSAE(使用兩臺(tái)帶SSL加速長(zhǎng)的SSL安全網(wǎng)關(guān)服務(wù)器，并配置為熱備部

署模式)建立128位SSL加密通信通道。

系統(tǒng)應(yīng)用服務(wù)器通過有NSAE經(jīng)由Web服務(wù)器傳過來的Request對(duì)象獲取

客戶端證書(假如客戶端使用數(shù)字證書認(rèn)證的話)。在登錄環(huán)節(jié)，系統(tǒng)應(yīng)用服務(wù)

器通過身份認(rèn)證及簽名驗(yàn)證服務(wù)器(NetSignServer)所提供的API驗(yàn)證用戶證

書有效性并完成登錄。

在交易過程中需要對(duì)交易簽名時(shí)，通過客戶端簽名控件對(duì)頁面信息進(jìn)行簽

名，簽名結(jié)果信息及原始信息傳遞至應(yīng)用服務(wù)器后，通過簽名驗(yàn)證服務(wù)器

(NetSignServer)提供的API將簽名結(jié)果與原始信息與客戶端證書傳至簽名驗(yàn)

證服務(wù)器進(jìn)行驗(yàn)證。

一次性口令的驗(yàn)證由系統(tǒng)應(yīng)用程序調(diào)用動(dòng)態(tài)密碼系統(tǒng)的服務(wù)適配器，由動(dòng)態(tài)

密碼服務(wù)器完成驗(yàn)訐并返回結(jié)果。短信密碼的發(fā)送，由動(dòng)態(tài)密碼服務(wù)器向的短信

網(wǎng)關(guān)SMSGateway發(fā)送請(qǐng)求實(shí)現(xiàn)。

3.3網(wǎng)絡(luò)層方案選擇

3.3.1安全連接協(xié)議

系統(tǒng)客戶端至服務(wù)器端的安全連接常見的協(xié)議有SSL、SPKM可供選擇匕

SPKM(SimplePublicKeyMechanism)協(xié)議，用于建立點(diǎn)對(duì)點(diǎn)之間的安全

通道，結(jié)合數(shù)字證書要緊適用于內(nèi)聯(lián)網(wǎng)環(huán)境，在運(yùn)用于互聯(lián)網(wǎng)時(shí)有如下問題⑸：

1.因客戶端在跟服務(wù)器端建立連接時(shí)需要訪問CRL,而SPKM協(xié)議固有的

原因會(huì)造成客戶端對(duì)廢止列表訪問的時(shí)間過長(zhǎng)。

2.SPKM協(xié)議在客戶端對(duì)整個(gè)頁面進(jìn)行數(shù)字簽名也是沒有必要的，并不是

用戶提交的所有頁面都需要數(shù)字簽名的，而且就算某個(gè)頁面需要數(shù)字簽名通常也

不是頁面中所有的元素都是需要數(shù)字簽名的。比如關(guān)于行外轉(zhuǎn)賬交易而言，收款

人姓名、收款人賬號(hào)、收款人開戶行、轉(zhuǎn)賬金額、付款人賬號(hào)是其五要素，客戶

在提交轉(zhuǎn)賬交易時(shí)只需對(duì)這五要素進(jìn)行數(shù)字簽名就能夠了，而頁面上還有一些諸

如是否發(fā)送Email通知等要素就沒必再被簽名了c超出需求的要素被簽名，一方

面將會(huì)增加網(wǎng)絡(luò)流量，同時(shí)還會(huì)導(dǎo)致服務(wù)器相應(yīng)的遲滯。

3.由于SPKM協(xié)議并非普遍使用的安全通訊協(xié)議，因此在通用的瀏覽器如

IE、Navigator等中沒有支持，需要下載安裝客戶端軟件，這就增加了系統(tǒng)安裝、

保護(hù)、使用的難度。

SSL(SecuritySocketLayer)協(xié)議已得到各主流瀏覽器內(nèi)置的支持。由于標(biāo)

準(zhǔn)的SSL協(xié)議，在使用客戶端證書時(shí)，并未對(duì)用戶的交易數(shù)據(jù)進(jìn)行顯式簽名，

造成應(yīng)用系統(tǒng)無法記錄交易數(shù)據(jù)的數(shù)字簽名，給在技術(shù)層面保護(hù)交易的不可否認(rèn)

性帶來了一定的困難咒

在應(yīng)用系統(tǒng)中我們使用SSL協(xié)議來建立安全連接。SSL協(xié)議簽名的問題可通

過在客戶瀏覽器端安裝簽名控件來完成，簽名控件一方面能夠完成數(shù)字簽名，另

一方面，通過自定義簽名格式，只對(duì)需要的頁面要素進(jìn)行簽名，去除不必要的數(shù)

據(jù)被簽名。

3.3.2安全區(qū)域的劃分

通過三臺(tái)防火墻將網(wǎng)絡(luò)劃分為四個(gè)邏輯區(qū)域，按由外到內(nèi)的順序部署。第一

道防火墻之外是Internel區(qū)（非授信區(qū)）；第一道防火墻與第二道防火墻之間是

Web區(qū)，在此區(qū)域中部署SSL服務(wù)器與應(yīng)用系統(tǒng)與網(wǎng)站系統(tǒng)的Web服務(wù)器等其

它第三方應(yīng)用系統(tǒng)；第二道防火墻與第三道防火墻之間是系統(tǒng)及網(wǎng)站的應(yīng)用/DB

區(qū)，在此區(qū)域中部署應(yīng)用服務(wù)器與數(shù)據(jù)庫服務(wù)器；第三道防火墻之后為其它的核

心系統(tǒng)、中間業(yè)務(wù)平臺(tái)等第三方業(yè)務(wù)系統(tǒng)。

3.3.2網(wǎng)絡(luò)層安全組件

應(yīng)用系統(tǒng)的最外端部署了綠盟黑洞抗DoS攻擊系統(tǒng)COLLAPSAR600D-5-B,

以操縱拒絕式攻擊與分布式拒絕攻擊；防火墻使用的是天融信防火墻產(chǎn)品

NGFW4000-G,入侵檢測(cè)則使用的是啟明入侵檢測(cè)NS500系統(tǒng)，漏洞掃描軟件

使用的是冠群金辰承影網(wǎng)絡(luò)漏洞掃描器，原有系統(tǒng)被兩道防火墻分隔成三個(gè)區(qū)。

系統(tǒng)部署時(shí)要求在停火區(qū)中再增加一道防火墻，一方面隔離Web服務(wù)器與

應(yīng)用服務(wù)器；另一方面隔離應(yīng)用服務(wù)器與其它核心系統(tǒng)。增加的防火墻依然使用

的是天融信NGFW4000-G防火墻，此外還增加了兩臺(tái)IBMTotalStorageSAN

16M-2的交換機(jī)，一套啟明NS500系統(tǒng)。

3.4系統(tǒng)層方案選擇

系統(tǒng)Web服務(wù)器的操作系統(tǒng)使用SUSELinux9Enterprise,應(yīng)用服務(wù)器與數(shù)

據(jù)庫服務(wù)器的操作系統(tǒng)使用AIX5L,V5.3,數(shù)據(jù)庫管理系統(tǒng)使用Oracle10.0.2

FORAIXo

由于軟件系統(tǒng)通常都存在漏洞，操作系統(tǒng)也不例外，不管是Unix、Linux還

是Windows系統(tǒng)。操作系統(tǒng)要求定期安裝系統(tǒng)的最新補(bǔ)丁，并定期對(duì)審計(jì)日志

進(jìn)行檢查與備份。另外，UNIX、Linux、NT系統(tǒng)通常包含許多網(wǎng)絡(luò)服務(wù)應(yīng)用程

序，如FTP、Teine【等，有些不必要的網(wǎng)絡(luò)服務(wù)程序務(wù)必禁用并關(guān)閉對(duì)應(yīng)的端口。

3.5應(yīng)用層方案選擇

3.5.1數(shù)字證書

國(guó)外比較著名的數(shù)字證書有：Verisign>Etrust、Baltimore等；國(guó)內(nèi)應(yīng)用比較

廣泛的數(shù)字證書要緊有中國(guó)金融認(rèn)證中心CFCA的數(shù)字證書、上海數(shù)字證書認(rèn)

證中心SHECA的證書等；另外有些實(shí)體建設(shè)了自己的CA,向本實(shí)體內(nèi)的系統(tǒng)

及其客戶發(fā)放數(shù)字證書。

對(duì)比分析上述的幾家認(rèn)證中心的數(shù)字證書的優(yōu)缺點(diǎn)將有助于安全子系統(tǒng)的

數(shù)字證書的選擇。下表是比較結(jié)果：

表8認(rèn)證中心比較的表格

方案優(yōu)點(diǎn)缺點(diǎn)

CFCA良好的公信力，是金融領(lǐng)域高級(jí)證書費(fèi)用較高，但可使

CA的權(quán)威用普通證書。

VeriSign國(guó)際的發(fā)證權(quán)威機(jī)構(gòu)國(guó)外機(jī)構(gòu)，發(fā)證手續(xù)煩惱，

費(fèi)用也不低。

自建CA發(fā)證成本較低仍需購(gòu)買發(fā)證軟件；銀行不

具備管理CA的專長(zhǎng)（大量的管理

工作）；法律問題（非授信第三

方）等等。

3.5.2動(dòng)態(tài)密碼輔助解決方案

動(dòng)態(tài)密碼方案是以一次性口令技術(shù)為基礎(chǔ)的，目前成熟的產(chǎn)品要緊有智能

卡、刮刮卡、動(dòng)態(tài)短信系統(tǒng)等，產(chǎn)品供應(yīng)商要緊有RSA、Todos等。

應(yīng)用系統(tǒng)可使用動(dòng)態(tài)密碼系統(tǒng)作為身份認(rèn)證的輔助解決方案，Todos動(dòng)態(tài)密

碼系統(tǒng)能夠使用手機(jī)短信的方式向客戶端發(fā)送一次性口令，客戶端僅需有一臺(tái)能

夠同意短信的手機(jī)就能夠了，這種方案客戶端幾乎沒有投入成本，造價(jià)也相對(duì)低

廉，安全性強(qiáng)。除手機(jī)短信方式，動(dòng)態(tài)密碼系統(tǒng)還有下列幾種客戶端的終端可供

選擇：

智能卡，以IC卡為載體，IC卡的內(nèi)置芯片實(shí)現(xiàn)某個(gè)密碼算法，卡內(nèi)同時(shí)儲(chǔ)

存了用戶的種子，每次按某種序列計(jì)算出不確定因子。智能K通常還有個(gè)啟動(dòng)

PIN碼，提供對(duì)智能卡持有人的認(rèn)證，加強(qiáng)智能卡的安全性。智能卡具有攜帶方

便，保密性好，即使卡遺失也不怕被他人利用等優(yōu)點(diǎn)，缺點(diǎn)就是成本相對(duì)較高。

刮刮卡，就是通過一次性口令技術(shù)事先算出一次性口令的子集或者全集，將

這些口令印制在一張卡片上，再在每個(gè)口令上涂蓋上防讀層，以后每次使用時(shí)按

系統(tǒng)提示刮開相應(yīng)位置的涂層，便得到當(dāng)次的口令，這種卡便稱之刮刮卡。刮刮

卡具有成本低，使用方便的優(yōu)點(diǎn)，安全性要比智能卡的低，一旦遺失有可能被他

人利用。

動(dòng)態(tài)密碼系統(tǒng)的使用一方面加強(qiáng)了應(yīng)用系統(tǒng)的安全性，另一方面也增加了客

戶選擇認(rèn)證措施的余地。

3.6系統(tǒng)運(yùn)行環(huán)境

3.6.1硬件配置

/Web主機(jī)

表9Web主機(jī)的配置表

型號(hào)數(shù)量配置備注

0penpower7101G.1CPU,SUSE91HD2*73Gwebserver1門戶用

0penpower7101G.1CPU,SUSE91HD2*73Gwebserver2門戶用

0penpower7101G.1CPU,SUSE91HD2*73Gwebserver3應(yīng)用用

0penpower7101G,1CPU,SUSE91HD2*73Gwebserver4應(yīng)用用

/NSAE

表10NSAE加速卡的配置表

型號(hào)