WEB網(wǎng)站系統(tǒng)安全解決方案

1、 網(wǎng)站系統(tǒng)安全的需求分析本文從數(shù)據(jù)安全和業(yè)務(wù)邏輯安全兩個角度對應(yīng)用系統(tǒng)的安全進(jìn)行需求分析，主要包括保密性需求、完整性需求、可用性需求三部分；隨后對業(yè)務(wù)邏輯安全需求進(jìn)行了分析，包括身份認(rèn)證、訪問控制、交易重復(fù)提交控制、異步交易處理、交易數(shù)據(jù)不可否認(rèn)性、監(jiān)控與審計等幾個方面；最后還分析了系統(tǒng)中一些其它的安全需求。2.1 數(shù)據(jù)安全需求2.1.1數(shù)據(jù)保密性需求數(shù)據(jù)保密性要求數(shù)據(jù)只能由授權(quán)實體存取和識別，防止非授權(quán)泄露。從目前國內(nèi)應(yīng)用的安全案例統(tǒng)計數(shù)據(jù)來看，數(shù)據(jù)保密性是最易受到攻擊的一個方面，通常表現(xiàn)為客戶端發(fā)生的數(shù)據(jù)泄密，包括用戶的基本信息、賬戶信息、登錄信息等的泄露。在應(yīng)用系統(tǒng)中，數(shù)據(jù)保密性需求通常

2、主要體現(xiàn)在以下幾個方面：A客戶端與系統(tǒng)交互時輸入的各類密碼：包括系統(tǒng)登錄密碼、轉(zhuǎn)賬密碼、憑證查詢密碼、憑證交易密碼等必須加密傳輸及存放，這些密碼在應(yīng)用系統(tǒng)中只能以密文的方式存在，其明文形式能且只能由其合法主體能夠識別。以網(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)賬密碼由用戶在柜面開戶時指定，用戶在首次登錄網(wǎng)銀系統(tǒng)時，系統(tǒng)必須強(qiáng)制用戶修改初始密碼，通常要求長度不得少于六位數(shù)，且不能是類似于111111、1234567、9876543等的簡單數(shù)字序列，系統(tǒng)將進(jìn)行

3、檢查。網(wǎng)銀轉(zhuǎn)賬密碼是指網(wǎng)銀系統(tǒng)為鞏固用戶資金安全，在涉及資金變動的交易中對用戶身份進(jìn)行了再認(rèn)證，要求用戶輸入預(yù)設(shè)的密碼，網(wǎng)銀交易密碼僅針對個人用戶使用，企業(yè)用戶沒有網(wǎng)銀交易密碼。建立多重密碼機(jī)制，將登錄密碼與網(wǎng)銀轉(zhuǎn)賬密碼分開管理，有利于加強(qiáng)密碼的安全性。由于用戶在使用網(wǎng)銀時每次都必須先提供登錄密碼，故登錄密碼暴露的機(jī)會較多，安全性相對較弱；但登錄網(wǎng)銀的用戶并不是每次都會操作賬戶資金的，所以專門設(shè)定網(wǎng)銀轉(zhuǎn)賬密碼可加強(qiáng)賬戶的安全性。網(wǎng)銀轉(zhuǎn)賬密碼在網(wǎng)銀開戶時設(shè)定，網(wǎng)銀用戶在系統(tǒng)中作轉(zhuǎn)賬支付、理財、代繳費(fèi)等資金變動類交易時使用。柜面交易密碼是指用戶在銀行柜面辦理儲蓄時，針對儲蓄憑證（如卡折、存單等）而

4、設(shè)的密碼。柜面交易密碼常用于POS系統(tǒng)支付時、ATM取款時、憑證柜面取款時，柜面交易密碼一個明顯的特征是它目前只能是六位的數(shù)字，這是由于目前柜面密碼輸入設(shè)備的限制而造成的。柜面交易密碼與上述的網(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)中認(rèn)證使用；而柜面交易密碼產(chǎn)生于銀行柜臺，可以在外圍渠道如ATM、電話銀行、自助終端上修改，它保存在銀行核心系統(tǒng)中，供外圍各個渠道系統(tǒng)共同使用。另外網(wǎng)銀轉(zhuǎn)賬密碼可以有非數(shù)字字符組成，而柜面交易密碼只能是六位的數(shù)字。網(wǎng)銀中使用到柜面交易密碼的交易包括：網(wǎng)銀開戶、加掛賬戶。一次性密碼由用戶的智能卡、令牌卡產(chǎn)生，或

5、由動態(tài)密碼系統(tǒng)產(chǎn)生通過短信方式發(fā)送到用戶注冊的手機(jī)上。一次性密碼的作用與網(wǎng)銀轉(zhuǎn)賬密碼相同，適用的場合也相同。一次性密碼在農(nóng)商行網(wǎng)銀系統(tǒng)中是可選的安全服務(wù)，用戶需到柜面辦理開通手續(xù)才能使用，沒有開通一次性密碼服務(wù)的用戶必須設(shè)定網(wǎng)銀交易密碼，開通一次性密碼服務(wù)的用戶則無需設(shè)定網(wǎng)銀交易密碼，要求網(wǎng)銀系統(tǒng)自動判斷并提示用戶在某個交易中是要輸入網(wǎng)銀交易密碼還是提示一次性密碼。B應(yīng)用系統(tǒng)與其它系統(tǒng)進(jìn)行數(shù)據(jù)交換時在特定安全需求下需進(jìn)行端對端的加解密處理。這里的數(shù)據(jù)加密主要是為了防止交易數(shù)據(jù)被銀行內(nèi)部人士截取利用，具體通訊加密方案參照應(yīng)用系統(tǒng)的特定需求。 2.1.2數(shù)據(jù)完整性需求數(shù)據(jù)完整性要求防止非授權(quán)實體對

6、數(shù)據(jù)進(jìn)行非法修改。用戶在跟應(yīng)用系統(tǒng)進(jìn)行交互時，其輸入設(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)的通訊過程中，另外存儲在應(yī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ù)可用性最典型的攻擊就是拒絕式攻擊（DoS）和分布式拒絕攻擊，兩者都是通過大量并發(fā)的惡意請

7、求來占用系統(tǒng)資源，致使合法用戶無法正常訪問目標(biāo)系統(tǒng)，如SYN Flood攻擊等，將會直接導(dǎo)致其他用戶無法登錄系統(tǒng)。另外，應(yīng)用登錄機(jī)器人對用戶的密碼進(jìn)行窮舉攻擊也會嚴(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)證就是確定某個個體身份的過程。系統(tǒng)通過身份認(rèn)證過程以識別個體的用戶身份，確保個體為所宣稱的身份。應(yīng)用系統(tǒng)中身份認(rèn)證可分為單向身份認(rèn)證和雙向身份認(rèn)證，單向身份認(rèn)證是指應(yīng)用系統(tǒng)對用戶進(jìn)行認(rèn)證，而雙向身份認(rèn)證則指應(yīng)用系統(tǒng)和用戶進(jìn)行互相認(rèn)證，雙向身份認(rèn)證可有效防止“網(wǎng)絡(luò)釣魚”等假網(wǎng)站對真正系統(tǒng)

8、的冒充。應(yīng)用服務(wù)器采用數(shù)字證書，向客戶端提供身份認(rèn)證，數(shù)字證書要求由權(quán)威、獨(dú)立、公正的第三方機(jī)構(gòu)頒發(fā)；系統(tǒng)為客戶端提供兩種可選身份認(rèn)證方案，服務(wù)器端對客戶端進(jìn)行多重身份認(rèn)證，要求充分考慮到客戶端安全問題。將客戶端用戶身份認(rèn)證與賬戶身份認(rèn)證分開進(jìn)行，在用戶登錄系統(tǒng)時，采用單點用戶身份認(rèn)證，在用戶提交更新類、管理類交易請求時，再次對用戶的操作進(jìn)行認(rèn)證或?qū)τ脩羯矸葸M(jìn)行二次認(rèn)證，以確保用戶信息安全。2.2.2訪問控制需求訪問控制規(guī)定了主體對客體訪問的限制，并在身份識別的基礎(chǔ)上，根據(jù)身份對提出資源訪問的請求加以控制。訪問控制是應(yīng)用系統(tǒng)中的核心安全策略，它的主要任務(wù)是保證應(yīng)用系統(tǒng)資源不被非法訪問。主體、客

9、體和主體對客體操作的權(quán)限構(gòu)成訪問控制機(jī)制的三要素。訪問控制策略可以劃分為自主訪問控制、強(qiáng)制訪問控制和基于角色的訪問控制三種。交易重復(fù)提交控制需求交易重復(fù)提交就是同一個交易被多次提交給應(yīng)用系統(tǒng)。查詢類的交易被重復(fù)提交將會無故占用更多的系統(tǒng)資源，而管理類或金融類的交易被重復(fù)提交后，后果則會嚴(yán)重的多，譬如一筆轉(zhuǎn)賬交易被提交兩次則將導(dǎo)致用戶的賬戶被轉(zhuǎn)出兩筆相同額的資金，顯然用戶只想轉(zhuǎn)出一筆。交易被重復(fù)提交可能是無意的，也有可能是故意的：A用戶的誤操作。在B/S結(jié)構(gòu)中，從客戶端來看，服務(wù)器端對客戶端的響應(yīng)總有一定的延遲，這在某些交易處理上體現(xiàn)的更為明顯，特別是那些涉及多個系統(tǒng)交互、遠(yuǎn)程訪問、數(shù)據(jù)庫全表掃

10、描、頁面數(shù)據(jù)簽名等交易，這種延遲通常都會在5至7秒以上。這時用戶有可能在頁面已提交的情況下，再次點擊了提交按鈕，這時將會造成交易被重復(fù)提交。B被提交的交易數(shù)據(jù)有可能被拿來作重放攻擊。應(yīng)用系統(tǒng)必須對管理類和金融類交易提交的次數(shù)進(jìn)行控制，這種控制即要有效的杜絕用戶的誤操作，還不能影響用戶正常情況下對某個交易的多次提交。比如說：當(dāng)某個用戶在10秒內(nèi)提交了兩筆相同的轉(zhuǎn)賬業(yè)務(wù)，則系統(tǒng)必須對此進(jìn)行控制；另一方面，當(dāng)用戶在第一筆轉(zhuǎn)賬業(yè)務(wù)完成后，再作另一筆數(shù)據(jù)相同的轉(zhuǎn)賬時，則系統(tǒng)不能對此進(jìn)行誤控制。這里判斷的依據(jù)就是交易重復(fù)提交的控制因子a，當(dāng)交易提交的間隔小于a時，系統(tǒng)認(rèn)為這是重復(fù)提交，提交間隔大于a的則不

11、作處理，控制因子的大小由應(yīng)用系統(tǒng)業(yè)務(wù)人員決定，系統(tǒng)應(yīng)可對其進(jìn)行配置化管理。2.2.4異步交易處理需求所謂異步交易就是指那些錄入與提交不是同時完成的交易，這里的同時是指客戶端在錄入交易數(shù)據(jù)與提交交易的過程中，應(yīng)用系統(tǒng)服務(wù)器端并沒有對錄入的數(shù)據(jù)進(jìn)行持久化保存，而異步交易在系統(tǒng)處理過程中，錄入與提交時間上發(fā)生在兩個相分離的階段，在兩階段之間，應(yīng)用系統(tǒng)對錄入的數(shù)據(jù)進(jìn)行了持久化保存。由于異步交易是被系統(tǒng)分兩階段受理的，這就涉及到以下三個方面的問題：錄入與提交的關(guān)系管理。如何保證提交的數(shù)據(jù)就是用戶當(dāng)初錄入的數(shù)據(jù)。如何記錄交易在兩階段的日志狀態(tài)。錄入與提交的關(guān)系定義不當(dāng)將會導(dǎo)致交易錄入與提交被同時完成而違反

12、了業(yè)務(wù)處理流程，錄入的數(shù)據(jù)被系統(tǒng)保存后有可能遭到非法篡改，非異步交易執(zhí)行后的日志狀態(tài)不會被更新而異步交易在提交后日志狀態(tài)將會被更新。應(yīng)用系統(tǒng)中需要定義成異步的交易通常有以下兩類：需要授權(quán)的交易。出于業(yè)務(wù)管理和業(yè)務(wù)安全方面的考慮，大部分管理類和金融類的交易都需要經(jīng)過一定的授權(quán)流程后方能被提交。部分定時交易，如預(yù)約轉(zhuǎn)賬等。預(yù)約一筆在周三轉(zhuǎn)賬的預(yù)約轉(zhuǎn)賬有可能是周一被錄入的，用戶在錄入后，預(yù)約轉(zhuǎn)賬的數(shù)據(jù)將被網(wǎng)銀系統(tǒng)保存直到周三這筆轉(zhuǎn)賬才會真正發(fā)生。應(yīng)用系統(tǒng)必須定義簡單、清晰、易維護(hù)的錄入與提交關(guān)系模型，保證被保存的錄入數(shù)據(jù)不會被非法篡改，同時要求異步交易的日志狀態(tài)是明確的，不應(yīng)出現(xiàn)錄入與提交相矛盾的日

13、志狀態(tài)。2.2.5交易數(shù)據(jù)不可否認(rèn)性需求交易數(shù)據(jù)不可否認(rèn)性是指應(yīng)用系統(tǒng)的客戶不能否認(rèn)其所簽名的數(shù)據(jù)，客戶對交易數(shù)據(jù)的簽名是通過應(yīng)用系統(tǒng)使用客戶的數(shù)字證書來完成的。數(shù)字證書的應(yīng)用為交易數(shù)據(jù)不可否認(rèn)性提供了技術(shù)支持，而電子簽名法的頒布為交易數(shù)據(jù)不可否認(rèn)性提供了法律基礎(chǔ)。在應(yīng)用系統(tǒng)中通常要求對所有管理類與金融類的交易進(jìn)行數(shù)字簽名，以防客戶事后對交易或交易數(shù)據(jù)的抵賴。應(yīng)用系統(tǒng)需同時保存客戶錄入的原始數(shù)據(jù)和簽名后的數(shù)據(jù)，保存期限依業(yè)務(wù)部門的具體要求而定?？紤]到系統(tǒng)性能和對用戶的響應(yīng)問題，應(yīng)用系統(tǒng)可只簽與交易有關(guān)的關(guān)鍵數(shù)據(jù)，支付類的交易只對付款人賬號、付款金額、收款人姓名、收款人賬號、收款人開戶行五個字段

14、進(jìn)行數(shù)字簽名就可以了。2.2.6監(jiān)控與審計需求安全級別要求高的應(yīng)用系統(tǒng)應(yīng)提供對系統(tǒng)進(jìn)行實時監(jiān)控的功能，監(jiān)控的內(nèi)容包括系統(tǒng)當(dāng)前登錄的用戶、用戶類型、用戶正在訪問的交易、用戶登錄的IP等。對金融類、管理類的交易以及應(yīng)用系統(tǒng)登錄交易需要完整地記錄用戶的訪問過程，記錄的關(guān)鍵元素包括：用戶登錄名、登錄IP、交易日期及時間、交易名稱、交易相關(guān)數(shù)據(jù)等，對有授權(quán)流程的交易要求完整記錄授權(quán)的經(jīng)過，授權(quán)記錄與交易記錄分開存放。 2.3 其它安全需求2.3.1 登錄控制需求登錄通常是應(yīng)用系統(tǒng)的關(guān)鍵交易，系統(tǒng)通過登錄交易對用戶身份進(jìn)行認(rèn)證。針對不同角色的用戶指定不同的登錄策略：最小權(quán)限集用戶，可使用用戶登錄名+靜態(tài)登

15、錄密碼+圖形識別碼方式登錄。低安全性。普通權(quán)限集用戶，可使用用戶登錄名+動態(tài)登錄密碼+數(shù)圖形識別碼方式登錄。高權(quán)限集用戶，可使用用戶登錄名+數(shù)字證書+靜態(tài)密碼+數(shù)圖形識別碼方式登錄。所有權(quán)限集用戶，可使用用戶登錄名+數(shù)字證書+動態(tài)密碼+數(shù)圖形識別碼方式登錄。應(yīng)用系統(tǒng)可提供客戶端加密控件對用戶輸入的密碼域進(jìn)行加密處理后再提交。連續(xù)登錄多次失敗的用戶，其IP將被應(yīng)用系統(tǒng)鎖定，24小時后系統(tǒng)將自動對鎖定的IP進(jìn)行解鎖。這里登錄失敗的次數(shù)和IP鎖定時長根據(jù)業(yè)務(wù)需求說明應(yīng)由配置文件進(jìn)行設(shè)定。對于首次登錄系統(tǒng)的用戶，系統(tǒng)將強(qiáng)制定位到修改密碼的頁面，要求用戶修改初始密碼重新登錄方可使用系統(tǒng)。對于密碼類型和長

16、度，系統(tǒng)將規(guī)則檢查。對于成功登錄的用戶，應(yīng)用系統(tǒng)自動清除其連續(xù)登錄失敗的次數(shù)，同時初始化用戶的相關(guān)數(shù)據(jù)并同時對登錄數(shù)據(jù)進(jìn)行記錄，以備審計。2.3.2 會話控制需求通過應(yīng)用服務(wù)器自身的會話管理或應(yīng)用程序的會話管理都可以控制會話的時長設(shè)定，設(shè)置過久的會話將給客戶端帶來安全風(fēng)險，而設(shè)置過短則影響用戶的正常使用。該機(jī)制使在應(yīng)用層無狀態(tài)的HTTP/HTTPS協(xié)議，能夠支持需要狀態(tài)記錄的互聯(lián)網(wǎng)應(yīng)用，實現(xiàn)用戶登錄后在新的狀態(tài)下從事交易、超時斷路等功能。2.3.3 被訪問對象控制需求應(yīng)用系統(tǒng)對用戶的關(guān)鍵資源或信息，提供操作權(quán)限設(shè)置支持，權(quán)限分為：查詢和更新兩類。權(quán)限為查詢的資源或信息只能對其進(jìn)行查詢操作，不能

17、進(jìn)行更新。資源權(quán)限由開戶時指定，為加強(qiáng)安全性，權(quán)限分配可通過落地處理開通。2.3.4 交易提醒需求交易提醒是指將客戶的賬號與客戶手機(jī)號、電子郵件等關(guān)聯(lián)起來，當(dāng)客戶信息發(fā)生變動時，向客戶的手機(jī)發(fā)送一條短信或電話通知或發(fā)送一封電子郵件，及時準(zhǔn)確的告知客戶。另通過通知提醒功能，系統(tǒng)應(yīng)定期向用戶發(fā)送統(tǒng)計、明細(xì)、確認(rèn)等信息。第三章 應(yīng)用系統(tǒng)安全的總體解決方案3.1 安全技術(shù)安全技術(shù)是安全子系統(tǒng)的理論基礎(chǔ)，安全子系統(tǒng)中主要涉及的安全技術(shù)包括：密碼技術(shù)、PKI技術(shù)體系、一次性口令技術(shù)等，另外考慮到目前實際應(yīng)用中，大部分WEB應(yīng)用系統(tǒng)是基于J2EE平臺的，J2EE平臺本身也對系統(tǒng)安全提供了較多內(nèi)置的支持，如J

18、AAS技術(shù)等，所以本章中對于J2EE平臺的安全技術(shù)特性也有少量的討論。3.1.1 密碼技術(shù)密碼技術(shù)是保護(hù)信息系統(tǒng)安全的基礎(chǔ)技術(shù)之一，密碼技術(shù)可以保證數(shù)據(jù)的保密性和完整性，同時它還具有身份認(rèn)證和數(shù)字簽名的功能。從密碼體制方面來說，密碼技術(shù)可分為對稱密鑰密碼技術(shù)和非對稱密鑰密碼技術(shù)兩大類。在應(yīng)用系統(tǒng)中常用的密碼技術(shù)主要有以下幾種：A加密解密技術(shù)加密（Encryption）就是指通過特定的加密算法對數(shù)據(jù)進(jìn)行變換，將明文（Plaintext）轉(zhuǎn)換成密文（Cryptograph）；解密（Decryption）是加密的逆過程，解密的過程就是將密文還原為明文。設(shè)明文為P，密文為C，E為加密算法，D為解密算法

19、，則加密解密的過程可以記為： (3.1)上述的加密與解密過程沒有使用到密鑰，通常稱之為無密鑰密碼體制。無密鑰密碼主要依靠加密算法提供保密性，在應(yīng)用系統(tǒng)中這種密碼很少用到，主要使用還是有密鑰的密碼體制，在有密鑰的密碼體制中，密文的保密性依賴于密鑰而不依賴于算法，算法可以公開。其中，只有一個密鑰K的密碼體制稱為單鑰體制（One-key System），又稱對稱加密體制（Symmetrical Encryption）；有加密密鑰KE和解密密鑰KD兩個密鑰的密碼體制稱為雙鑰體制（Two-key System），又稱非對稱加密體制（Dissymmetrical Encryption），有時也叫公開密鑰算

20、法（Public Key Algorithm)。應(yīng)用系統(tǒng)中經(jīng)常使用最廣泛的對稱加密算法是DES算法 (Data Encryption Standard)，非對稱加密算法是RSA算法（Receive，Shamir，Adelman）。單鑰體制的加密解密過程可以記為： (3.2)上式用圖示可以表示為：明文密文明文加密密鑰K解密密鑰K圖5 單鑰體制加密解密過程圖雙鑰體制的加密解密過程可以記為： (3.3)上式用圖示可以表示為： 明文密文明文加密密鑰KE解密密鑰KD圖6 雙鑰體制加密解密過程圖還有一種應(yīng)用系統(tǒng)中經(jīng)常用到的加密技術(shù)是數(shù)據(jù)摘要，數(shù)據(jù)摘要就是應(yīng)用單向散列函數(shù)算法，將輸入的任意長度明文變換成固定

21、長度的密文，而將此密文再轉(zhuǎn)換成明文在數(shù)學(xué)上來說是困難的。應(yīng)用系統(tǒng)中應(yīng)用最廣泛的數(shù)據(jù)摘要算法主要有MD5和SHA兩種，MD5輸出壓縮值為128bits，SHA輸出壓縮值為160bits。設(shè)Hash表示單向散列函數(shù)，則數(shù)據(jù)摘要的過程可以記為： (3.4)上式用圖示可以表示為：明文密文明文加密密鑰K解密密鑰K密文明文Hash圖7 數(shù)據(jù)摘要的過程圖B數(shù)字簽名。數(shù)字簽名是指通過密碼算法對原始數(shù)據(jù)信息進(jìn)行加密處理后，生成一段原始數(shù)據(jù)信息的信息標(biāo)識，這段信息標(biāo)識稱為原始數(shù)據(jù)信息的數(shù)字簽名。通常數(shù)字簽名和原始數(shù)據(jù)信息是放在一起發(fā)送的，這樣便于信息的接受者對其進(jìn)行驗證，數(shù)字簽名是對現(xiàn)實中手寫簽名和印章的模擬，數(shù)

22、字簽名只有信息發(fā)送方一人能產(chǎn)生，這種唯一性對應(yīng)了原始數(shù)據(jù)信息的來源。數(shù)字簽名具有驗證數(shù)據(jù)完整性和信息來源不可否認(rèn)性的功能，這正是PKI體系提供的核心功能。在應(yīng)用系統(tǒng)中，較小的數(shù)據(jù)可以直接簽名，而較大的數(shù)據(jù)或文件通常先對其作數(shù)據(jù)摘要后再對數(shù)據(jù)摘要作數(shù)字簽名。下式表達(dá)了對一段原始數(shù)據(jù)信息進(jìn)行簽名的過程：原始數(shù)據(jù)信息OriginalMsg先是被單向散列函數(shù)Hash作數(shù)據(jù)摘要生成摘要信息DigestMsg，然后應(yīng)用非對稱加密算法DissymmetricalEncrypt及其私鑰Keyprivate對數(shù)據(jù)摘要進(jìn)行簽名（私鑰僅有發(fā)送方持有，公鑰需散發(fā)給接收方），最后將簽名結(jié)果DigitalSignatur

23、e與原始數(shù)據(jù)信息一起發(fā)送給接受方： (3.4)上式用圖示可以表示為：OriginalMsgKeyprivavteDigitalSignatureHashDissymmetricalEncrytDigestOriginalMsg + DigitalSignature圖8 數(shù)字簽名的過程圖信息接受方在接受到原始數(shù)據(jù)信息OriginalMsg與其數(shù)字簽名DigitalSignature后，可以對數(shù)字簽名進(jìn)行驗證。首先分離出兩者，然后對原始數(shù)據(jù)信息應(yīng)用同樣的單向散列函數(shù)Hash對其作數(shù)據(jù)摘要得到Digest2，再對接收到的數(shù)字簽名應(yīng)用非對稱加密算法DissymmetricalEncrypt及其公鑰Ke

24、ypublic對其進(jìn)行解密，得到Digest1。比較Digest1與Digest2，如果兩者一樣則證明：1信息OriginalMsg及其數(shù)字簽名DigitalSignature是真實的，確實來自于私鑰Keyprivate的持有方。2信息OriginalMsg及其數(shù)字簽名DigitalSignature在發(fā)送過程中是完整的，未曾遭到篡改。3私鑰Keyprivate的持有方發(fā)送了信息OriginalMsg及其數(shù)字簽名DigitalSignature這件事是不可否認(rèn)的。上述數(shù)字簽名的驗證過程可以表達(dá)為： (3.5)用圖形表示如下：KeypublicOriginalMsgDigitalSignatur

25、eHashDissymmetricalEncrytDigest2OriginalMsg + DigitalSignatureDigest2兩者相同？圖9 數(shù)字簽名驗證的過程圖C報文識別碼應(yīng)用系統(tǒng)跟其它系統(tǒng)通訊時大都是通過發(fā)送接收報文方式進(jìn)行的，除比較常用的ISO8583，sop報文等，還有比較多的就是自定義的報文格式，自定義報文需要解決報文的保密性和完整性問題，報文的完整性可以通過加密算法生成原始報文的報文標(biāo)識來識別，這個加密后的報文標(biāo)識稱為原始報文的識別碼，也叫報文校驗碼MAC（Message Authentication Code）。而報文的保密性可以通過對整個報文及其識別碼進(jìn)行加密處理來

26、完成，實際應(yīng)用中識別碼通?？梢酝ㄟ^單向散列函數(shù)對原始報文作數(shù)據(jù)摘要得到，然后對原始報文和數(shù)據(jù)摘要作對稱加密，這樣既保證了報文的完整性，同時也保證了報文的保密性，這里對稱加密算法的密鑰分發(fā)是主要問題。D數(shù)字信封數(shù)字信封DE（Digital Envelope）是指信息發(fā)送方在通訊雙發(fā)首次通訊時，使用對方的公鑰對雙方的通訊密鑰SK（Symmentric Key）進(jìn)行加密，形成一個數(shù)字信封，然后發(fā)給接收方，接收方收到數(shù)字信封后進(jìn)行拆封操作，用自己的私鑰對信封進(jìn)行解密得到通訊密鑰，然后雙方可以用通訊密鑰對自己發(fā)送的信息進(jìn)行對稱加密2。這樣既解決了對稱加密的密鑰分配問題又提高了雙方通訊加密的效率，畢竟非對

27、稱加密算法比對稱加密算法效率要低下。3.1.2 PKI體系PKI體系是由政策機(jī)構(gòu)、認(rèn)證機(jī)構(gòu)和注冊機(jī)構(gòu)組成的，通過使用單向散列函數(shù)、非對稱加密體制等加密解密技術(shù)，安全套接字協(xié)議SSL，LDAP協(xié)議（Lightweight Directory Access Protocol），X.509證書標(biāo)準(zhǔn)等技術(shù)，實現(xiàn)數(shù)據(jù)加密、身份認(rèn)證和數(shù)字簽名等功能，從而保證數(shù)據(jù)保密性、完整性、真實性和不可否認(rèn)性的一種技術(shù)體系。PKI體系很好的解決了網(wǎng)上銀行的大部分安全需求，對網(wǎng)上銀行的數(shù)據(jù)安全和業(yè)務(wù)邏輯安全提供了有力的支持。CA是PKI體系的主要實體，數(shù)字證書是CA的主要產(chǎn)品，CA通過數(shù)字證書的應(yīng)用來實現(xiàn)PKI體系所提供

28、的功能。1PKI的組成PKI由政策批準(zhǔn)機(jī)構(gòu)PAA、政策CA機(jī)構(gòu)PCA、認(rèn)證機(jī)構(gòu)CA和注冊機(jī)構(gòu)RA組成。PAA創(chuàng)建整個PKI系統(tǒng)的方針、政策，批準(zhǔn)本PAA下屬的PCA的政策，為下屬PCA簽發(fā)公鑰證書，建立整個PKI體系的安全策略，并具有監(jiān)控個PCA行為的責(zé)任。PCA制定自身的具體政策，包括密鑰的產(chǎn)生、密鑰的長度、證書的有效期規(guī)定及CRL的處理等，同時PCA為其下屬CA簽發(fā)公鑰證書。CA按照上級PCA制定的政策，為具體用戶簽發(fā)、生成并發(fā)布數(shù)字證書，負(fù)責(zé)CRL的管理與維護(hù)。RA負(fù)責(zé)接收用戶的證書申請，驗證用戶的身份，向CA提交證書申請，驗證接收CA簽發(fā)的數(shù)字證書，并將證書發(fā)放給申請者。PKI的組成圖

29、示如下：PCA1RA1PAAPCAnRAnCAnRAnRA1CAnCA1CA1圖10 PKI的體系結(jié)構(gòu)圖2PKI的操作功能證書的生成及分發(fā)。在用戶向RA提交數(shù)字證書申請后，RA負(fù)責(zé)對申請者的身份進(jìn)行認(rèn)證，認(rèn)證通過后RA將向CA轉(zhuǎn)發(fā)證書申請。CA負(fù)責(zé)生成用戶的數(shù)字證書，數(shù)字證書的公私密鑰對可以由用戶產(chǎn)生，也可以由CA產(chǎn)生。用戶自己產(chǎn)生的公鑰需提交給CA，CA對公鑰強(qiáng)度驗證后將根據(jù)用戶提交的公鑰產(chǎn)生用戶的數(shù)字證書；如果是CA產(chǎn)生用戶的公私密鑰對，則CA不保存用戶的私鑰，私鑰需通過安全的方式發(fā)放給用戶。CA生成證書后將其發(fā)布到相應(yīng)的目錄服務(wù)器上。證書的獲取。在PKI體系中，要獲取某個用戶的數(shù)字證書，

30、可以RA處獲得，也可以查詢CA的證書目錄服務(wù)器，另外用戶也可以將自己的證書發(fā)送給別人。證書的廢止。數(shù)字證書的持證人如果發(fā)生證書丟失、密鑰泄漏時，持證人可以向CA或RA提交證書廢止請求，CA將會把用戶的證書加入到廢止列表中。廢止列表CRL的獲取與查詢。由于CRL通常都比較大，在線查詢效率比較低下，所以現(xiàn)在通常在RA端建立一個CRL的鏡像，定期將CA端的CRL同步到本地，同步又分全部CRL同步和增量同步兩種，全部CRL同步的好處能保證CRL數(shù)據(jù)一致，缺點是同步的數(shù)據(jù)量龐大，通常也沒有必要進(jìn)行全局同步。增量同步就是每次只同步CA端新增的CRL部分，增量同步的數(shù)據(jù)量較小，比較符合現(xiàn)實。CRL的查詢可以

31、通過LDAP等訪問。證書恢復(fù)。證書恢復(fù)功能為客戶在證書存儲介質(zhì)損壞或遺忘口令等情況下，提供原證書的恢復(fù)，申請者向RA或CA提出證書恢復(fù)請求，CA將會為用戶生成新的數(shù)字證書，原來的證書將作廢，同時還會將其加入CRL中。證書更新。證書更新用于解決客戶證書到期后的續(xù)費(fèi)問題，也有可能是客戶的證書并未到達(dá)有效期而是CA或RA的本身的數(shù)字證書到達(dá)了有效期。這時用戶需更新證書，CA將會為用戶簽發(fā)新的數(shù)字證書。3PKI的服務(wù)功能PKI提供的服務(wù)功能包括：數(shù)據(jù)保密性服務(wù)、數(shù)據(jù)完整性服務(wù)、數(shù)據(jù)真實性服務(wù)、數(shù)據(jù)不可否認(rèn)性服務(wù)和身份認(rèn)證服務(wù)。這些服務(wù)都是通過數(shù)字證書的應(yīng)用來實現(xiàn)的，在集成這些服務(wù)時，還需要應(yīng)用系統(tǒng)作部

32、分支持才能真正實現(xiàn)這些服務(wù)。3.1.3 一次性口令技術(shù)所謂一次性口令（OTP，One Time Password）是指針對傳統(tǒng)可重復(fù)使用的口令而言的。一次性口令只能使用一次，不可重復(fù)使用?？芍赜玫目诹钜资芊N種攻擊：截取攻擊：當(dāng)口令以明文方式在網(wǎng)絡(luò)上傳遞時，容易被攻擊者截取獲得，一旦口令泄漏則可能被未授權(quán)者非法使用。重放攻擊：當(dāng)口令以密文方式在網(wǎng)絡(luò)上傳遞時，雖然攻擊者無法獲取口令的明文，但攻擊者可以截取口令密文后對系統(tǒng)實施重放攻擊。窮舉攻擊：攻擊者還有可能針對用戶的登錄名，根據(jù)系統(tǒng)對口令的限定規(guī)則，嘗試規(guī)則范圍內(nèi)各個可能的口令，對用戶口令實施窮舉攻擊。窺探：用戶在輸入可重復(fù)使用的口令時必然要借助

33、某種輸入設(shè)備，如鍵盤、鼠標(biāo)、手寫筆等，這時容易被他人或其它錄影設(shè)備窺探到輸入內(nèi)容，也有可能被木馬程序等記錄了擊鍵事件而分析出口令。社交工程：攻擊者通過利用人們心理弱點、本能反應(yīng)、好奇心、信任、貪婪等心理陷阱通過電子郵件、電話訪談、釣魚網(wǎng)站等騙取用戶的口令。垃圾搜索：攻擊者偽裝成垃圾工人收集用戶的垃圾文檔用以分析用戶的口令等。一次口令由于每次使用各不相同的口令，所以并不存在上述的問題。一次口令并不要求用戶記住多個口令，所以也不會增加用戶和系統(tǒng)的負(fù)擔(dān)。一次性口令的原理：在客戶端和服務(wù)器端各存在一個相同的算法、一個與用戶有關(guān)的種子、一個不確定的因子，每次系統(tǒng)對用戶進(jìn)行認(rèn)證時，用戶將不確定的因子追加到

34、種子后，然后用算法對其加密算出一個結(jié)果，這個結(jié)果作為一個一次性口令提交給服務(wù)器，服務(wù)器端用相同的算法對相同種子和不確定因子進(jìn)行運(yùn)算，將得出的結(jié)果與用戶提交的結(jié)果進(jìn)行比較，相同則說明用戶輸入的口令是正確的。一次性口令技術(shù)要求服務(wù)器端具有與用戶端相同的算法、種子及不確定因子。這里關(guān)鍵是如何保證客戶端、服務(wù)器端具有相同的不確定因子。兩端不確定因子的選擇方式主要有以下三種：1挑戰(zhàn)應(yīng)答方式。每次用戶請求登錄系統(tǒng)時，服務(wù)器端將不確定因子發(fā)送給用戶，稱為一次挑戰(zhàn)，而用戶提交的口令是根據(jù)發(fā)送來的不確定因子，和用戶端保存的種子，由用戶端保存的算法計算出來的，所以每次計算出的口令不相同。這里的算法可以采用單向散列

35、函數(shù)算法，也可以采用對稱加密算法。不確定因子采用挑戰(zhàn)應(yīng)答方式的原理可以圖示如下：返回登錄結(jié)果運(yùn)用算法對種子和因子進(jìn)行運(yùn)算得出登錄口令并提交發(fā)送不確定因子請求登錄，輸入用戶名用 戶系 統(tǒng)圖11 一次性口令應(yīng)用的原理圖2時間同步方式。客戶端和服務(wù)器端以時間作為不確定因子，這里要求雙方的時間是嚴(yán)格同步的，精確度可以控制在約定的范圍內(nèi)，比如說雙方的時間差不超過一分鐘。3事件同步方式?？蛻舳撕头?wù)器端以單向序列的迭代值作為不確定因子，這里要求雙方每次迭代值的大小相同。這種方式的實現(xiàn)代價比時間同步方式的小得多，而且也不用向挑戰(zhàn)應(yīng)答方式那樣多出個挑戰(zhàn)的交互，這種方式客戶端以單向迭代作為挑戰(zhàn)，迭代作為規(guī)則可以

36、在客戶端實現(xiàn)。3.1.3 基于J2EE平臺的相關(guān)安全技術(shù)1語言內(nèi)置的安全技術(shù)Java語言具有強(qiáng)類型檢查，在編譯時就能對變量類型進(jìn)行檢查；自動內(nèi)存管理，在C、C+中內(nèi)存的分配和回收都需要程序員負(fù)責(zé)完成，在大型應(yīng)用中內(nèi)存泄漏是個頗為棘手的問題，而Java內(nèi)置垃圾回收機(jī)制，由系統(tǒng)負(fù)責(zé)內(nèi)存的管理；字節(jié)碼檢查，JVM（Java Virtual Machine）對源代碼編譯生成的字節(jié)碼進(jìn)行檢查，防止惡意代碼對運(yùn)行環(huán)境的破壞；安全的類裝載機(jī)制，確保不信任的代碼不會影響其它Java程序的運(yùn)行。2密碼技術(shù)支持JCA（Java Cryptography Architecture）和JCE（Java Cryptog

37、raphic Extension）為加密、解密、數(shù)字證書、數(shù)據(jù)摘要提供完整的支持；提供對各種密碼算法的支持，包括RSA、DSA、DES、SHA等；提供對PKCS#11的支持。3認(rèn)證和訪問控制支持JAAS（Java Authentication and Authorization Service）和Policy的實現(xiàn)及語法等提供了細(xì)粒度的訪問控制，抽象的認(rèn)證APIs可以插件方式靈活地集成到其它登錄控制系統(tǒng)中。4安全通訊Java Secure Socket Extension (JSSE)，Java GSS-API (JGSS)，Java Simple Authentication and Sec

38、urity Layer API（SASL）等提供對Transport Layer Security (TLS)、SSL、Kerberos、SASL等協(xié)議的實現(xiàn)，提供對基于SSL/TLS的HTTPS完全支持，為的數(shù)據(jù)完整性、保密性提供支持確保通訊安全。5為PKI提供支持J2EE提供管理密鑰和證書的工具，廣泛抽象的APIs對X.509證書、廢止列表、證書路徑、OCSP (On-Line Certificate Status Protocol)、PKCS#11、PKCS#12、LDAP等提供支持，大大簡化了PKI應(yīng)用開發(fā)和部署的難度3。3.2 網(wǎng)絡(luò)總體結(jié)構(gòu)應(yīng)用系統(tǒng)的總體拓?fù)鋱D參考如下示：圖12 應(yīng)用

39、系統(tǒng)的總體拓?fù)鋱D參考用戶通過Internet網(wǎng)絡(luò)向應(yīng)用系統(tǒng)發(fā)起請求，請求在到達(dá)Web服務(wù)器之前將通過NSAE（使用兩臺帶SSL加速卡的SSL安全網(wǎng)關(guān)服務(wù)器，并配置為熱備部署模式）建立128位SSL加密通信通道。系統(tǒng)應(yīng)用服務(wù)器通過有NSAE經(jīng)由Web服務(wù)器傳過來的Request對象獲取客戶端證書（如果客戶端采用數(shù)字證書認(rèn)證的話）。在登錄環(huán)節(jié)，系統(tǒng)應(yīng)用服務(wù)器通過身份認(rèn)證及簽名驗證服務(wù)器（NetSign Server）所提供的API驗證用戶證書有效性并完成登錄。在交易過程中需要對交易簽名時，通過客戶端簽名控件對頁面信息進(jìn)行簽名，簽名結(jié)果信息及原始信息傳遞至應(yīng)用服務(wù)器后，通過簽名驗證服務(wù)器（NetSi

40、gn Server）提供的API將簽名結(jié)果和原始信息以及客戶端證書傳至簽名驗證服務(wù)器進(jìn)行驗證。一次性口令的驗證由系統(tǒng)應(yīng)用程序調(diào)用動態(tài)密碼系統(tǒng)的服務(wù)適配器，由動態(tài)密碼服務(wù)器完成驗證并返回結(jié)果。短信密碼的發(fā)送，由動態(tài)密碼服務(wù)器向的短信網(wǎng)關(guān)SMS Gateway發(fā)送請求實現(xiàn)。3.3 網(wǎng)絡(luò)層方案選擇3.3.1 安全連接協(xié)議系統(tǒng)客戶端至服務(wù)器端的安全連接常見的協(xié)議有SSL、SPKM可供選擇4。SPKM（Simple Public Key Mechanism）協(xié)議，用于建立點對點之間的安全通道，結(jié)合數(shù)字證書主要適用于內(nèi)聯(lián)網(wǎng)環(huán)境，在運(yùn)用于互聯(lián)網(wǎng)時有如下問題5：1因客戶端在跟服務(wù)器端建立連接時需要訪問CRL，

41、而SPKM協(xié)議固有的原因會造成客戶端對廢止列表訪問的時間過長。2SPKM協(xié)議在客戶端對整個頁面進(jìn)行數(shù)字簽名也是沒有必要的，并不是用戶提交的所有頁面都需要數(shù)字簽名的，而且就算某個頁面需要數(shù)字簽名通常也不是頁面中所有的元素都是需要數(shù)字簽名的。比如對于行外轉(zhuǎn)賬交易而言，收款人姓名、收款人賬號、收款人開戶行、轉(zhuǎn)賬金額、付款人賬號是其五要素，客戶在提交轉(zhuǎn)賬交易時只需對這五要素進(jìn)行數(shù)字簽名就可以了，而頁面上還有一些諸如是否發(fā)送Email通知等要素就沒必再被簽名了。超出需求的要素被簽名，一方面將會增加網(wǎng)絡(luò)流量，同時還會導(dǎo)致服務(wù)器相應(yīng)的遲滯。3由于SPKM協(xié)議并非普遍采用的安全通訊協(xié)議，因此在通用的瀏覽器如I

42、E、Navigator等中沒有支持，需要下載安裝客戶端軟件，這就增加了系統(tǒng)安裝、維護(hù)、使用的難度。SSL（Security Socket Layer）協(xié)議已得到各主流瀏覽器內(nèi)置的支持。由于標(biāo)準(zhǔn)的SSL協(xié)議，在采用客戶端證書時，并未對用戶的交易數(shù)據(jù)進(jìn)行顯式簽名，造成應(yīng)用系統(tǒng)無法記錄交易數(shù)據(jù)的數(shù)字簽名，給在技術(shù)層面維護(hù)交易的不可否認(rèn)性帶來了一定的困難6。在應(yīng)用系統(tǒng)中我們采用SSL協(xié)議來建立安全連接。SSL協(xié)議簽名的問題可通過在客戶瀏覽器端安裝簽名控件來完成，簽名控件一方面可以完成數(shù)字簽名，另一方面，通過自定義簽名格式，只對需要的頁面要素進(jìn)行簽名，去除不必要的數(shù)據(jù)被簽名。3.3.2 安全區(qū)域的劃分通

43、過三臺防火墻將網(wǎng)絡(luò)劃分為四個邏輯區(qū)域，按由外到內(nèi)的順序部署。第一道防火墻之外是Internet區(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ù)平臺等第三方業(yè)務(wù)系統(tǒng)。3.3.2 網(wǎng)絡(luò)層安全組件應(yīng)用系統(tǒng)的最外端部署了綠盟黑洞抗DoS攻擊系統(tǒng)COLLAPSAR600D-5-B，以控制拒絕式攻擊和分布式拒絕攻擊；防火墻采用的是天融信防火墻產(chǎn)品NGFW4000-G，入侵檢測

44、則采用的是啟明入侵檢測NS500系統(tǒng)，漏洞掃描軟件采用的是冠群金辰承影網(wǎng)絡(luò)漏洞掃描器，原有系統(tǒng)被兩道防火墻分隔成三個區(qū)。系統(tǒng)部署時要求在?；饏^(qū)中再增加一道防火墻，一方面隔離Web服務(wù)器與應(yīng)用服務(wù)器；另一方面隔離應(yīng)用服務(wù)器和其它核心系統(tǒng)。增加的防火墻依然采用的是天融信NGFW4000-G防火墻，此外還增加了兩臺IBM TotalStorage SAN 16M-2的交換機(jī)，一套啟明NS500系統(tǒng)。3.4 系統(tǒng)層方案選擇系統(tǒng)Web服務(wù)器的操作系統(tǒng)采用SUSE Linux 9 Enterprise，應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器的操作系統(tǒng)采用AIX5L，V5.3，數(shù)據(jù)庫管理系統(tǒng)采用Oracle 10.0.2

45、 FOR AIX。由于軟件系統(tǒng)通常都存在漏洞，操作系統(tǒng)也不例外，無論是Unix、Linux還是Windows系統(tǒng)。操作系統(tǒng)要求定期安裝系統(tǒng)的最新補(bǔ)丁，并定期對審計日志進(jìn)行檢查和備份。另外，UNIX、Linux、NT系統(tǒng)一般包含許多網(wǎng)絡(luò)服務(wù)應(yīng)用程序，如FTP、Telnet等，有些不必要的網(wǎng)絡(luò)服務(wù)程序必須禁用并關(guān)閉對應(yīng)的端口。3.5 應(yīng)用層方案選擇3.5.1 數(shù)字證書國外比較著名的數(shù)字證書有：Verisign、Etrust、Baltimore等；國內(nèi)應(yīng)用比較廣泛的數(shù)字證書主要有中國金融認(rèn)證中心CFCA的數(shù)字證書、上海數(shù)字證書認(rèn)證中心SHECA的證書等；另外有些實體建設(shè)了自己的CA，向本實體內(nèi)的系統(tǒng)

46、及其客戶發(fā)放數(shù)字證書。對比分析上述的幾家認(rèn)證中心的數(shù)字證書的優(yōu)缺點將有助于安全子系統(tǒng)的數(shù)字證書的選擇。下表是比較結(jié)果：表8 認(rèn)證中心比較的表格方案優(yōu)點缺點CFCA良好的公信力，是金融領(lǐng)域CA的權(quán)威高級證書費(fèi)用較高，但可采用普通證書。VeriSign國際的發(fā)證權(quán)威機(jī)構(gòu)國外機(jī)構(gòu)，發(fā)證手續(xù)麻煩，費(fèi)用也不低。自建CA發(fā)證成本較低仍需購買發(fā)證軟件；銀行不具備管理CA的專長（大量的管理工作）；法律問題（非授信第三方）等等。3.5.2 動態(tài)密碼輔助解決方案動態(tài)密碼方案是以一次性口令技術(shù)為基礎(chǔ)的，目前成熟的產(chǎn)品主要有智能卡、刮刮卡、動態(tài)短信系統(tǒng)等，產(chǎn)品供應(yīng)商主要有RSA、Todos等。應(yīng)用系統(tǒng)可采用動態(tài)密碼系

47、統(tǒng)作為身份認(rèn)證的輔助解決方案，Todos動態(tài)密碼系統(tǒng)可以采用手機(jī)短信的方式向客戶端發(fā)送一次性口令，客戶端僅需有一臺可以接受短信的手機(jī)就可以了，這種方案客戶端幾乎沒有投入成本，造價也相對低廉，安全性強(qiáng)。除手機(jī)短信方式，動態(tài)密碼系統(tǒng)還有以下幾種客戶端的終端可供選擇：智能卡，以IC卡為載體，IC卡的內(nèi)置芯片實現(xiàn)某個密碼算法，卡內(nèi)同時儲存了用戶的種子，每次按某種序列計算出不確定因子。智能卡通常還有個啟動PIN碼，提供對智能卡持有人的認(rèn)證，加強(qiáng)智能卡的安全性。智能卡具有攜帶方便，保密性好，即使卡遺失也不怕被他人利用等優(yōu)點，缺點就是成本相對較高。刮刮卡，就是通過一次性口令技術(shù)事先算出一次性口令的子集或全集

48、，將這些口令印制在一張卡片上，再在每個口令上涂蓋上防讀層，以后每次使用時按系統(tǒng)提示刮開相應(yīng)位置的涂層，便得到當(dāng)次的口令，這種卡便稱為刮刮卡。刮刮卡具有成本低，使用方便的優(yōu)點，安全性要比智能卡的低，一旦遺失有可能被他人利用。動態(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ī)表9 Web主機(jī)的配置表型號數(shù)量配置備注Openpower710 1G,1 CPU, SUSE 91HD 2*73Gweb server 1 門戶用Openpower710 1G,1 CPU, SUSE 91HD 2*73Gweb serv

49、er 2 門戶用Openpower710 1G,1 CPU, SUSE 91HD 2*73Gweb server 3 應(yīng)用用Openpower710 1G,1 CPU, SUSE 91HD 2*73Gweb server 4 應(yīng)用用NSAE表10 NSAE加速卡的配置表型號數(shù)量配置備注InfoSec NSAE 加速卡版1HD 2*73GInfoSec NSAE 加速卡版1HD 2*73G應(yīng)用主機(jī)和數(shù)據(jù)庫主機(jī)表11 應(yīng)用主機(jī)和數(shù)據(jù)庫主機(jī)的配置表型號數(shù)量配置備注P550 4G 2CPU， AIX5.3L1HD 2*73GP550 4G 2CPU， AIX5.3L1HD 2*73GNETSIGN表1

50、2 數(shù)字簽名驗證設(shè)備的配置表型號數(shù)量配置備注InfoSec NETSIGN1HD 2*73GSAN SWITH表13 交換機(jī)的配置表型號數(shù)量配置備注IBM TotalStorage SAN 16M-228口磁盤陣列表14 磁盤陣列的配置表型號數(shù)量配置備注DS43001HD 8*73G7+1 冗余 RAID53.6.2 軟件配置Web服務(wù)器表15 Web服務(wù)器的配置表型號數(shù)量備注IBM HTTP SERVER 6.0 1CFCA RA1Dynamic Password Server1應(yīng)用服務(wù)器表16 應(yīng)用服務(wù)器的配置表型號數(shù)量備注IBM WebSphere 6.0.2 ND1數(shù)據(jù)庫服務(wù)器表17

51、數(shù)據(jù)庫服務(wù)器的配置表型號數(shù)量備注Oracle 10.0.2 FOR AIX1雙機(jī)熱備軟件表18 雙機(jī)熱備軟件的配置表型號數(shù)量備注HACMP 5.3 FOR AIX 5.31附錄資料：不需要的可以自行刪除WEB服務(wù)器控件在ASP.NET中，Web Form能容納的對象主要是Server Control（服務(wù)器端控件）?？丶蟹?wù)器端的，因為這些控件都是服務(wù)器端來處理的。Server Control會在初始化的時候自動生成適合瀏覽器的HTML代碼。這樣在編寫ASP.NET程序的時候，就不必考慮瀏覽器的兼容性問題！ 服務(wù)器端控件的執(zhí)行過程是：先在服務(wù)器執(zhí)行，根據(jù)執(zhí)行結(jié)果生成html元素，然后發(fā)回給客

52、戶端瀏覽器。Web 服務(wù)器控件位于以 System.Web.UI.Webcontrols 命名的空間中，并集成在 ASP.NET 的基本類庫中，人們習(xí)慣稱為 Web 控件。像 HTML 服務(wù)器控件一樣，Web 服務(wù)器控件也 是被創(chuàng)建于服務(wù)器上并且需要 runat=server 屬性來工作。然而，Web 服務(wù)器控件不是必 須要映射到已存在的 HTML 元素，它們可以表現(xiàn)為更復(fù)雜的元素。2.1 WEB 服務(wù)器控件的格式Web 服務(wù)器控件有兩種具體格式。(1) 所有屬性均定義在一對尖括號“”內(nèi)，并以“asp:”作為前綴標(biāo)志，以“/”作 為結(jié)束標(biāo)志。其格式形式為：注意：屬性之間要空格分開。(2) 除了

53、 Text 屬性外，其他屬性均定義在一對尖括號內(nèi)，并以“asp:control_name” 作為前綴標(biāo)志，以“”作為結(jié)束標(biāo)志，Text 屬性放在尖括號和結(jié)束標(biāo)志 的中間。其格式形式為： text 注意：control_name為控件名。示例： 2.2 服務(wù)器控件的類型ASP.NET提供了兩種不同類型的服務(wù)器控件：HTML服務(wù)器控件和Web服務(wù)器控件。這兩種類型的控件大不相同，在使用ASP.NET時，就會看出重 點是Web服務(wù)器控件。這并不是說，HTML服務(wù)器控件沒有用，它們提供了許多功能，其中一些功能Web服務(wù)器控件也沒有。2.3 用服務(wù)器控件建立頁面使用服務(wù)器控件構(gòu)建ASP.NET頁面有兩種

54、方式?？梢钥梢暬匕芽丶戏诺皆O(shè)計界面上，操縱該控件的行為。也可以直接通過輸入代碼來處理服務(wù)器控件。2.3.1 在設(shè)計界面上使用服務(wù)器控件高級編程)Visual Studio 2005允許可視化地把控件拖放到設(shè)計界面上，可視化地創(chuàng)建ASP.NET頁面。要獲得這個可視化的設(shè)計選項，可以在查看ASP.NET頁面時，單擊 IDE底部的Design選項卡。在這個視圖中，可以把光標(biāo)放在希望控件出現(xiàn)的地方，再在Visual Studio的Toolbox窗口中雙擊需要的控件。在頁面的Design視圖中，可以突出顯示一個控件，該控件的屬性就會顯示在Properties窗口中。例如，在圖4-1中，在設(shè)計面板上選

55、擇Button控件，其屬性就顯示在右下角的Properties窗口中。圖 4-1在這個窗口中修改屬性，就會改變突出顯示的控件的外觀或行為。所有的控件都繼承了一個特定的基類(WebControl)，所以還可以同時突出顯示多個控件，一次改變這些控件的基本屬性。在選擇控件時，需要按住Ctrl鍵。2.3.2 在Source界面使用服務(wù)器控件與Design視圖一樣，頁面的Source視圖也允許把控件從Toolbox拖放到代碼頁面上。例如，把一個TextBox控件拖放到代碼頁面上，與把它拖放到設(shè)計界面上的效果相同：也可以在Source視圖中突出顯示一個控件，或把光標(biāo)放在該控件的代碼語句上，Properti

56、es窗口就會顯示該控件的屬性?，F(xiàn)在就可以直接應(yīng)用Visual Studio的Properties窗口中的屬性了，這些屬性會動態(tài)添加到控件的代碼中。2.3.3 處理服務(wù)器控件的事件例如，窗體上按鈕的一個常見事件是Button_Click，如程序清單所示。處理按鈕單擊事件protected void Button1_Click(object sender，EventArgs e) / Code actions here程序清單中的事件僅在終端用戶單擊了窗體上的按鈕時才觸發(fā)，該窗體具有Button1_Click的OnClick屬性值。所以事件處理程序不僅存在于ASP.NET頁面的服務(wù)器端代碼上，還使

57、 用相關(guān)的ASP.NET頁面標(biāo)記中的服務(wù)器控件的OnClick屬性關(guān)聯(lián)起來，如下面的代碼所示：如何觸發(fā)服務(wù)器控件的這些事件？有兩種方式。第 一種方式是在Design視圖中打開ASP.NET頁面，雙擊要創(chuàng)建服務(wù)器端事件的控件。例如，雙擊Design視圖中的Button服務(wù)器控件，無論代 碼是在后臺編碼文件中，還是內(nèi)置代碼，都會在服務(wù)器端代碼中創(chuàng)建Button1_Click事件的結(jié)構(gòu)。這會為該服務(wù)器控件最常用的事件創(chuàng)建一個處理程序 框架。如前所述，注意Button控件有非常多的事件，雙擊該控件并不能得到這些事件。為了訪問這些事件，應(yīng)打開包含服務(wù)器端代碼的頁面，從IDE頂部的第一個下拉列表中選擇該控

58、件，再在第二個下拉列表中 選擇該控件需要的事件。下圖顯示了事件下拉列表。例如，處理Button控件的PreRender事件，而不是其Click事件。該事件的處理程序會 放在服務(wù)器端代碼中。第二種方式是在Visual Studio的Properties窗口中為服務(wù)器控件創(chuàng)建服務(wù)器端的事件。這種方式只能用于頁面的Design視圖。在Design視圖中，突出顯示要 處理的服務(wù)器控件，該控件的屬性和一個圖標(biāo)菜單就會出現(xiàn)在Properties窗口中。其中一個圖標(biāo)是事件圖標(biāo)，用一個閃電圖形表示，如圖所示。單擊事件圖標(biāo)會打開該控件的可用事件列表。雙擊其中一個事件，就會在服務(wù)器端代碼中創(chuàng)建該事件的結(jié)構(gòu)。有了事

59、件的結(jié)構(gòu)后，就可以編寫觸發(fā)事件時希望發(fā)生的特定操作了。2.4 控件的常見屬性ASP.NET 2.0的許多服務(wù)器控件都派生于WebControl類，擁有公共屬性，并不是所有的服務(wù)器控件都派生于WebControl類中。例如，Literal、 PlaceHolder、Repeater和XML服務(wù)器控件就不是派生于WebControl基類，而是派生于Control類。HTML服務(wù)器控件也沒有派生于WebControl基類，因為它們主要用于設(shè)置HTML元素的屬性。表4-2列出了服務(wù)器控件都有的公共屬性。屬 性說 明AccessKey允許賦予與Alt鍵相關(guān)的一個字符，這樣終端用戶就可以使用鍵盤上的快捷鍵

60、激活控件了。例如，給Button 控件的AccessKey屬性賦予K。這樣，終端用戶就不需要單擊ASP.NET頁面上的按鈕(使用鼠標(biāo)控制的指針)，而可以按下Alt+K Attributes允許為Web服務(wù)器控件定義公共屬性未定義的額外屬性BackColor控制ASP.NET頁面上控件的背景色BorderColor給服務(wù)器控件的邊框設(shè)置顏色BorderWidth給組成控件邊框的線設(shè)置線寬值。把一個數(shù)字設(shè)置為該值，就是把該數(shù)字設(shè)置為邊框的寬度像素值。如果BorderColor屬性沒有與BorderWidth屬性設(shè)置一起使用，默認(rèn)的邊框顏色就是黑色BorderStyle允許指定服務(wù)器控件邊框的設(shè)計樣