网站系统安全防护体系建设方案
?
?
?
?
?
?
?
網站系統安全防護體系建設方案
?
?
?
?
?
?
?
?
?
?
?
?
?
?
目錄
一、需求說明... 2
二、網頁防篡改解決方案... 4
2.1 技術原理... 4
2.2 部署結構... 5
2.3 系統組成... 6
2.4 集群與允余部署... 8
2.5 方案特點... 9
2.5.1 篡改檢測和恢復... 9
2.5.2 自動發布和同步... 9
三、WEB應用防護解決方案... 11
3.1 當前安全風險分析... 11
3.2 防護計劃... 12
3.2.1 開發流程中加入安全性驗證項目... 12
3.2.2 對網站程序的源代碼進行弱點檢測... 13
3.2.3 導入網頁應用程序漏洞列表作為審計項目... 13
3.2.4 部署Web應用防火墻進行防御... 14
3.3????? WEB應用防火墻功能... 15
3.3.1 集中管控功能... 15
3.3.2 防護功能... 15
3.4 預期效益... 16
四、內容分發網絡解決方案... 18
4.1 內容分發網絡簡介... 18
4.2 ??? CDN服務功能... 18
4.3????? CDN服務特點... 20
五、負載均衡解決方案... 21
5.2 廣域負載均衡... 23
5.3 關鍵功能和特點... 24
六、應急響應服務體系... 26
6.1 事件分類與分級... 26
6.1.1 事件分類... 26
6.1.2 事件分級... 26
6.1.3 預警服務事件嚴重等級... 27
6.2 應急響應服務體系... 28
一、需求說明
針對Web應用防護安全需能實現以下功能：
一、針對網站主頁惡意篡改的監控，防護和快速恢復：
（1）支持多種保護模式，防止靜態和動態網頁內容被非法篡改。
（2）能夠防止主頁防護功能被惡意攻擊者非法終止。
（3）具備核心內嵌技術，能實現高效快速實現大規模的網頁攻擊防護。
（4）支持實時檢測和快速恢復功能。
（5）支持多服務器、多站點的主頁防護
（6）支持對常見的多種網頁文件類型的保護。
（7）支持網頁快照功能，根據需要即時提供快照頁面，以滿足客戶端的訪問。
二、 對Web網站進行多層次檢測分析與應用防護：
（1）有效保護網站靜動態網頁以及后臺DB信息，實現多方位攻擊防護。
（2）??? 靈活的策略設置，能夠針對各個WEB應用的特點，設置個性化的防護策略。
（3）不反射保護網站（或WEB應用）程序代碼防止受到各種已知攻擊（如SQL注入，跨站腳本，釣魚攻擊等）和未知攻擊；并能限制未授權用戶透過網站訪問數據中心，防止入侵者的通信流程。
（4）能夠根據操作系統、應用平臺及評估滲透工具等特征，形成完備的特征庫。綜合并發連接、并發請求及流量限制，阻斷攻擊探測或掃描； 同時能夠對訪問數據流進行協議檢查，防止對WEB應用的惡意信息獲取和特征收集。
三、行為審計：
（1）能夠記錄和有效統計用戶對WEB應用資源的訪問，包括頁面點擊率、 客戶對端地址、客戶端類型、訪問流量、訪問時間及搜索引擎關鍵字信息；并實現有效的用戶行為訪問統計分析，如基于區域的訪問統計，便于識別WEB應用的訪問群體是否符合預期，為應用優化提供依據。
（2）對攻擊來源和攻擊行為支持分類記錄探測，數據處理結果形成詳細的統計及排序，支持依據威脅的級別生成防護策略。
（3）提供多種審計報表，為系統的安全審計提供詳細的數據并作為可靠的決策依據。
四、支持多種WEB 應用加速技術，減輕服務器負載：
（1）支持URL 級別的流量管理和負載均衡，提供對頁面訪問的并發連接與速率進行控制，提高應用系統在資源緊張時的可用性。
（2）具備訪問過載保護能力，緩解WEB 服務因訪問量過大而造成的拒絕服務攻擊， 提高系統承受應用層DOS攻擊的服務能力。
（3）及時發現WEB 應用狀態異常，迅速反饋應用服務活動狀態，并選擇最優秀服務連接。
（4）支持輪詢、最小負載、請求URL 及加權等多種均衡策略，滿足各種應用環境下的均衡要求。
（5）網站主頁和WEB應用防護系統，需能分別以獨立方式及互備方式部署在不同機房。
?
二、網頁防篡改解決方案
Web網站和Web應用系統除了采用常見的網絡安全設備進行防護外，需要更有效的網頁防篡改系統來專門對頁面內容進行保護，防止來自外部或內部的非授權人員對頁面和內容進行篡改和非法添加。
?
2.1 技術原理
防篡改體系除了Web服務器外，另外需部署‘發布服務器’：
‐? 發布服務器：
位于內網中，本身處在相對安全的環境中，其上部署發布服務器軟件。所有網頁的合法變更（包括增加、修改、刪除、重命名）都在發布服務器上進行。發布服務器上具有與Web服務器上的網頁文件完全相同的目錄結構，發布服務器上的任何文件/目錄的變化都會自動和立即地反映到Web服務器的相應位置上，文件/目錄變更的方法可以是任意方式的（例如：FTP、SFTP、RCP、NFS、文件共享等）。網頁變更后，“發布服務器軟件”將其同步到Web服務器上。
‐?
| ? | |
| ? | ? |
Web服務器：
位于Internet/DMZ中，本身處在不安全的環境中，其上部署Web服務器端防篡改模塊及內容同步軟件模塊。
?
防篡改系統的運行原理：
n? 防篡改
對所有網頁元素（包括靜態頁面、動態腳本、圖像文件、多媒體文件以及所有能以URL形式訪問的實體）在發布時進行128位密鑰的HMAC-MD5（RFC2104）計算，生成唯一的、不可逆轉的和不可偽造的數字水印。
瀏覽者請求訪問任一網頁元素時，篡改檢測模塊（作為Web服務器軟件的一部分）讀出網頁元素的內容重新計算數字水印，并與之前存儲的數字水印進行比對，網頁元素的任何篡改都能夠被可靠地計算出來。
n? 防竊聽
任何通信實體（包括發布服務器和Web服務器和控制臺）之間采用工業標準的SSL3.0/TLS1.0安全通訊協議（RFC2246），確保網頁元素文件和數字水印數據流在通信過程中不被黑客竊取和分析。
n? 身份鑒別
通信實體間進行強身份鑒別。首先，Web服務器要確保上傳文件的發布服務器的身份真實性，不能接受偽造的發布服務器上傳的文件；其次，發布服務器要確保是在與Web服務器通信，確保發送的文件能夠到Web服務器上。因此，雙方彼此都進了身份鑒別。亦即：發布服務器采用客戶端數字證書與Web服務器通訊，同時也驗證Web服務器數字證書的真實性。
?
2.2 部署結構
?
| ? | |
| ? | ? |
目前，大部分網站都使用內容管理系統（CMS）來管理網頁產生的全過程，包括網頁的編輯、審核、簽發和合成等。在網站的網絡拓撲中，發布服務器部署在原有的內容管理系統和Web服務器之間，下圖表明三者之間的關系。
發布服務器上具有與Web服務器上的網站文件完全相同的目錄結構，任何文件/目錄的變化都會自動映射到Web服務器的相應位置上。
網頁的合法變更（包括增加、修改、刪除、重命名）都在發布服務器上進行，變更的手段可以是任意方式的（例如：FTP、SFTP、RCP、NFS、文件共享等）。網頁變更后，發布服務器將其同步到Web服務器上。無論什么情況下，不允許直接變更Web服務器上的頁面文件。
?
?
?
?
| ? | |
| ? | ? |
下圖為防篡改系統的邏輯部署圖。若無多余服務器可供使用，則發布服務器可與內容管理服務器建構在同一服務器上：
?
2.3 系統組成
從邏輯上，防篡改系統由頁面保護子系統、自動發布子系統和監控管理子系統組成，三部分的關系如下圖所示。
?
n? 頁面保護子系統
頁面保護子系統是系統的核心，內嵌在Web服務器軟件里（即前述的核心內嵌模塊），包含應用防護模塊和篡改檢測模塊。
應用防護模塊對每個用戶的請求進行安全性檢查：如果正常則發送給Web服務器軟件；如果發現有攻擊特征碼，即刻中止此次請求并進行報警。
篡改檢測模塊對每個發送的網頁進行即時的完整性檢查：如果網頁正常則對外發送；如果被篡改則阻斷對外發送，并依照一定策略進行報警和恢復。
對于Windows系統，頁面保護子系統還包括一個增強型事件觸發式檢測模塊，該模塊駐留于操作系統內核，阻止大部分常規篡改手段。
n? 自動發布子系統
自動發布子系統負責頁面的自動發布，由發送端和接收端組成：發送端位于發布服務器上，稱之為自動發布程序，它監測到文件系統變化即進行計算該文件水印，并進行SSL發送；接收端位于Web服務器上，稱之為同步服務器，它接收到網頁和水印后，將網頁存放在文件系統中，將水印存放在安全數據庫里。所有合法網頁的增加、修改和刪除都通過自動發布子系統進行。
n? 監控管理子系統
負責篡改后自動恢復，也提供系統管理員的使用界面。其功能包括：手工上傳、查看警告、檢測系統運行情況、修改配置、查看和處理日志等。
日志記錄所有系統、發布、篡改檢測和自動恢復等信息，可以分類分日期查看，并根據管理員的要求實現轉儲。日志記錄還支持syslog，以實現與安全管理平臺的接口。
?
2.4 集群與允余部署
?
| ? | |
| ? | ? |
Web站點運行的穩定性是最關鍵的，防篡改系統支持所有部件的多機工作和熱備，可以有多臺安裝了防篡改模塊和同步服務軟件的Web服務器，也可以有兩發布服務器，避免單點失效問題，如下圖所示。
?
n? Web服務器多機和集群
發布服務器支持1對多達64臺Web服務器的內容同步，這些Web服務器的操作系統、Web服務器系統軟件、應用腳本及網頁內容既可以相同也可以不同。本案提供的解決方案將可實現異種系統架構下對不同內容的統一管理。
n? 發布服務器雙機
支持發布服務器雙機協同工作，即一臺主發布服務器和一臺熱備發布服務器。在這種部署情形下，內容管理系統（CMS）需要將內容同時發布到兩臺發布服務器上。正常狀態下，主發布服務器工作時，由它對所有Web服務器進行內容同步。如果熱備發布服務器運行失效（不影響網站系統運行），一旦在它修復后可以從主發布服務器恢復數據，進入正常熱備狀態。主發布服務器如果失效（即不發心跳信號），熱備發布服務器會接管工作，由熱備服務器對所有Web服務器進行內容同步。當主發布服務器修復后，兩機同時工作，經過一段時間的數據交接時間，熱備發布服務器重新進入熱備狀態。
2.5 方案特點
2.5.1 篡改檢測和恢復
n? 支持安全散列檢測方法；
n? 可檢測靜態頁面/動態腳本/二進制實體；
n? 支持對注入式攻擊的防護；
n? 網頁發布同時自動更新水印值；
n? 網頁發送時比較網頁和水印值；
n? 支持斷線/連線狀態下篡改檢測；
n? 支持連線狀態下網頁恢復；
n? 網頁篡改時多種方式報警；
n? 網頁篡改時可執行外部程序或命令；
n? 可以按不同容器選擇待檢測的網頁；
n? 支持增強型事件觸發檢測技術；
n? 加密存放水印值數據庫；
n? 支持各種私鑰的硬件存儲；
n? 支持使用外接安全密碼算法。
2.5.2 自動發布和同步
n? 自動檢測發布服務器上文件系統任何變化；
n? 文件變化自動同步到多個Web服務器；
n? 支持文件/目錄的增加/刪除/修改/更名；
n? 支持任何內容管理系統；
n? 支持虛擬目錄/虛擬主機；
n? 支持頁面包含文件；
n? 支持雙機方式的冗余部署；
n? 斷線后自動重聯；
n? 上傳失敗后自動重試；
n? 使用SSL安全協議進行通信；
n? 保證通信過程不被篡改和不被竊聽；
n? 通信實體使用數字證書進行身份鑒別；
n? 所有過程有詳細的審計。
?
?
?
?
?
三、WEB應用防護解決方案
從網頁應用程序層面進行安全防護機制：
第一項計劃是，通過網頁程序代碼的安全檢測，找出潛在應用程序的編寫漏洞，提供開發團隊修補建議，并據以改寫修補。同時為網頁應用層防火墻提供防護規則，做到內外共同防護；
第二項計劃是，通過網頁應用層防火墻軟件的部署，與網頁程序代碼的安全檢測互相聯動，為在線運營的網站立即建立防護，針對各種應用層的攻擊進行阻擋，建立起網站從內而外的安全防護體系。
?
3.1 當前安全風險分析
越來越多的案例表明，網站的安全問題隨著各類網絡技術手段的不斷進步而顯現出來。截止到目前，以跨站腳本攻擊、SQL注入攻擊為代表的攻擊方式對傳統的‘防火墻+入侵防護’所組成的網站安全防線帶來了極大的沖擊；同時由于新的攻擊方式的出現，一旦網站被入侵，輕則網站被植入惡意連結或對象，導致訪問用戶的個人電腦中毒或被植入木馬；嚴重的話，通過網頁的接口導致客戶的信息或交易紀錄被入侵，從而面對的是漫長的調查、賠償、法律責任、甚至訴訟。如果被媒體披露的話，更會嚴重影響企事業單位的聲譽。
網站安全風險分析：
| 項次 | 大綱 | 說明 |
| 1 | 沒有適當機制確認目前的網頁程序存在哪些漏洞 | 目前已在線執行的網頁系統，是幾年來不斷開發與累積的結果。然而新興的以網頁應用程序為攻擊目標的攻擊模式不斷被發現，因此當前面臨的困難在于: l? 現有的開發團隊并非全職的安全專家，難以保證編寫出來的程序代碼絕對不會存在漏洞。 l? 在線的程序代碼為數眾多，如果要逐條人工檢視，絕對力有未逮，且現有的開發能力用于全力開發新的服務與流程改善，無法投入足夠的資源用于檢測舊的系統漏洞。 l? 經常性的發生信息安全事件，會讓團隊疲于奔命。也花費大量的資源來進行調查與修復。更不用說后續延伸出來的商譽損失、法律責任、甚至訴訟與賠償事宜。 |
| 2 | 網站的運營者往往都在網站遭受入侵與惡意攻擊后通過外界反應才知道 | 當黑客利用時下Web AP的攻擊手法，如Cross Site Script或SQL Injection等方式攻擊網站，而網站又剛好有未知的漏洞被利用，那么不僅缺乏適當的機制可以立即發現攻擊，更無法達到防御的效果。 |
| 3 | 法律責任的沖擊 | 企事業單位有責任妥善保管的客戶個人信息，若因網站被入侵而導致客戶信息外泄，則有可能必須面對法律責任的問題。 |
| 4 | 敏感信息顯示于網頁接口時，需進行屏蔽，避免會員信息外泄 | 針對如信用卡卡號或身分證字號等敏感信息，如果需要在網頁中顯示響應給使用者，則需要進行屏蔽，將中間字符內容取代為x或*等符號，避免使用者的計算機存在木馬或傳輸過程被竊聽，而造成信息外泄。 然而現有的系統已經運作多年，需要逐一檢視并且修改，需花費大量的資源與時間。 |
| 5 | 傳統IDS/IPS與防火墻，擋不住也看不懂 Web攻擊 | 原本期望通過IDS/IPS與防火墻來抵御黑客的攻擊。然而現在的黑客，不再「硬碰硬」的進行防火墻、入侵偵測系統或者修補程序可以阻擋的「網絡型攻擊」或者「作業平臺的攻擊」。目前超過 70% 成功的黑客攻擊，都是針對『 Web 應用程序』的弱點而不是操作系統的弱點，而且循著合法身份從Web 應用系統管道進入，因此原先的防火墻與入侵偵測系統也束手無策。 |
| 6 | SSL加密后的流量，無法從網絡端實施入侵檢查與過濾 | 因為運營的是電子商務服務，因此為避免使用者進行交易的過程中信息被從中竊聽，而實施HTTPS/SSL加密，保障傳輸過程的安全。 然而，這也造成部署網頁防入侵機制時的限制與困擾。因為如果使用的使網絡型的Web Application Firewall機制，SSL加密后的流量就會無法進行檢查，或者要改變現有SSL加密的處理流程。 |
?
3.2 防護計劃
3.2.1 開發流程中加入安全性驗證項目
在軟件開發流程中，擬規劃一套系統化的安全設計流程，確保網絡應用程序的安全。系統發展生命周期(Systems Development Life Cycle,簡稱SDLC)是大部分信息應用系統設計的參考模型，即一套應用程序軟件的發展需要歷經「分析」、「設計」、「建構」、「測試」、「系統維護」至下一次的需求產生，這一周期就是系統發展生命周期。安全系統發展生命周期(Security Systems Development Life Cycle )便是泛指在軟件開發生命周期中，應考慮的信息安全措施及注意事項。
3.2.2 對網站程序的源代碼進行弱點檢測
建議導入自動化網頁應用程序源代碼安全檢測體系。
不可否認的，早期所開發的應用程序，皆以「功能性」著眼，欠缺「安全性」的安全認識與危機意識，因此在程序編寫中較少考慮到「安全性」的問題，因此不小心便導致所開發的 Web 應用系統漏洞百出，導致 SQL Injection、緩沖區溢出（Buffer-Overflow）、跨網站腳本攻擊（Cross-Site Scripting）等等 Web攻擊。信息安全的相關領域知識包含「操作系統」、「開發工具」、「網站平臺」、「程序邏輯」、「程序編譯」、「程序執行」以及種種通訊協議原理，并非程序開發人員的專業領域，因此如何快速有效地針對單位內現有與未來開發建設的 Web 應用系統進行定期或者不定期檢驗其可能的源代碼弱點與漏洞，需要一套有系統有效率的「Web 應用系統原代碼自動檢測系統」，有助于提早發現并評估風險，提早進行源代碼改寫與修補動作。
Web 應用系統原代碼自動檢測系統所提供的服務特色為：
l? 針對程序源代碼檢測結果與報告，提供程序源代碼「弱點深度分析」與「弱點嚴重性分析」等風險高低評估計分與圖表，協助程序開發人員規劃安排程序源代碼弱點安全問題修復的優先級。
l? 清楚標明程序源代碼弱點安全問題的結果與源頭，協助開發與項目管理人員了解程序源代碼弱點安全問題之發生程序行數與弱點來源，必須包含下列信息：
l? 可與本案「Web 應用系統安全防火墻」的安全訪問策略聯動，解決復雜的應用防火墻配置問題。
3.2.3 導入網頁應用程序漏洞列表作為審計項目
開放網頁應用程序安全計劃(Open Web Application Security Project, 以下簡稱OWASP)致力協助企業和政府機關(構)能夠理解和提高網頁應用程序的安全性，并關注最嚴重的漏洞。OWASP于2010年最新公布的十大信息安全漏洞(OWASP Top 10)是一個需要立刻處理的應用程序安全漏洞。這些安全漏洞包括：
l? Cross-Site Scripting（跨站腳本攻擊）。網頁應用程序直接將來自使用者的執行請求送回瀏覽器執行，使得攻擊者可擷取使用者的Cookie或Session數據而能直接登入成使用者。
l? Injection Flaw：網頁應用程序執行來自外部包括數據庫在內的惡意指令，SQL注入,命令注入等攻擊包括在內。
l? Malicious File Execution：網頁應用程序引入來自外部的惡意檔案并執行檔案內容。
l? Insecure Direct Object Reference：攻擊者利用網頁應用程序本身的檔案讀取功能任意存取檔案或重要數據，案例包括http://example/read.php?file=../../../../../../../c:\boot.ini
l? Cross-Site Request Forgery (CSRF): 已登入網頁應用程序的合法使用者執行到惡意的HTTP指令，但網頁應用程序卻當成合法需求處理，使得惡意指令被正常執行，案例包括社交網站分享的 QuickTime、Flash影片中藏有惡意的HTTP請求。
l? Information Leakage and Improper Error Handling：網頁應用程序的執行錯誤訊息包含敏感數據，案例包括:系統檔案路徑
l? Broken Authentication and Session Management：網頁應用程序中自行編寫的身份驗證相關功能有缺陷。
l? Insecure Cryptographic Storage：網頁應用程序沒有對敏感性數據使用加密、使用較弱的加密算法或將密鑰儲存在容易被取得之處。
l? Insecure Communication：沒有在傳送敏感性數據時使用HTTPS或其它加密方式。
l? Failure to Restrict URL Access：某些網頁因為沒有權限控制，使得攻擊者可通過網址直接存取，案例包括允許直接修改Wiki或Blog網頁內容。
歸咎這些安全漏洞的根本原因，乃在于網頁應用程序本身存在安全漏洞，忽略應該注意的函數處理與防范來自使用者的惡意攻擊。倘若這些安全漏洞在開發與部署過程沒有被檢測出來，則日后就會發生信息安全事件。利用‘Web 應用系統原代碼自動檢測系統’所提供的檢測服務可事先發現網站所潛藏的上述安全漏洞。
3.2.4 部署Web應用防火墻進行防御
導入網頁應用程序防火墻系統的好處在于：
n? 網站源代碼檢測階段：
在修補源代碼中存在的安全隱患之前（可能因為開發團隊變更、服務無法暫停等原因暫時無法對安全隱患進行修補），則依靠網頁應用程序防火墻系統提供Web應用安全防護，從而保證網站應用的安全性；
n? 網站安全加固階段：
可以將網頁應用程序源代碼安全檢測系統檢測出的安全問題自動直接生成網頁應用程序防火墻系統所需使用的安全防護規則（Access Policy），使得網頁應用程序源代碼安全檢測系統與網頁應用程序防火墻系統產生互相聯動，從而做到網站應用安全的自動化防護。
通過網頁應用程序防火墻的部署，讓訪問者對網站的請求，以及網站預計響應給訪問者的顯示網頁，都經過「Web 應用系統安全防火墻」全程檢查與檢視其「安全性」、「合法性」與「正確性」，如有任何「非法行為」，自動「阻斷非法行為」或者「重置合法與合適的響應」，讓「使用者」與「系統管理者」都可以繼續「安心」的運作。
「Web 應用系統安全防火墻」部署架構如下圖：
?
?
3.3? WEB應用防火墻功能
3.3.1 集中管控功能
l?? 同一解決方案除了提供硬件式應用防護設備外，可依實際需求選擇將軟件式應用防火墻系統安裝于Web服務器主機上，不需要調整網絡與系統架構。
l?? 支持【集中叢集控管(Cluster Management)】方式，通過統一集中管理接口，同時管理與安全防護規則部署多臺「Web 應用系統軟件式防火墻系統」。
l?? 支持集群內各臺「Web 應用系統軟件式防火墻系統」運行狀態，如有異常，立即顯示。
l?? 具備多管理者、多網站群組的權限管理能力，提供讓特定管理者管理特定網站群組安全防護規則的能力
l?? 內建「Web 應用系統軟件式防火墻系統」紀錄查詢與查看工具，方便實時分析，提供多重條件過濾查詢功能，無須額外購置審計報表分析工具。
l?? 提供符合法規遵循角度需求的審計紀錄，詳細紀錄系統的操作與變更，方便審計人員查驗。
l?? 提供統計報表能力，提供多種預設統計圖表，支持自定義設定分析范圍與時間區段，產生滿足單位需求與法規遵循要求的報表。
l?? 提供直接過濾防護 SSL加密網頁的機制，安裝部署時，不需要更改 SSL 密鑰存放位置，避免密鑰管理的額外問題。
3.3.2 防護功能
l?? 可防御下列19大類(含)以上網頁攻擊型態，超過10,000種(含)以上網頁攻擊方法。
l?? 支持下列OWASP Top 10十大網頁應用程序弱點的攻擊模式。
l?? 提供「輸入驗證(Input Validation)」處理機制，提供黑名單或者白名單方式驗證使用者輸入內容數據的類型、范圍、格式與長度。
l?? 提供「客戶端瀏覽器存取權限」的管理能力，可以限制存取網站的客戶端IP地址、使用的瀏覽器版本、網頁開放存取的時間范圍 以及SSL加密的強度等等存取條件。
l?? 提供「網頁存取身份驗證(Authentication)」處理機制，讓缺乏賬號密碼等權限管理的網頁具備身份驗證能力。
l?? 提供「網頁存取安全會話(Secure Session)」處理機制，保護客戶端瀏覽器Cookie的安全使用，降低 Cookie 外泄的機率。
l?? 提供「網頁上傳下載雙向過濾保護」功能，通過關鍵詞過濾網站惡意內容或不當文字，或是防止機敏數據外泄。
l?? 針對網頁敏感信息，例如：信用卡信息、身份證號等隱私數據，提供「自動屏蔽(Auto Mask/XXX)」功能機制，避免單位機密數據或者個人隱私外泄。
l?? 提供「反釣魚(Anti-Phishing)」功能，可通過黑、白或灰名單方式限制釣魚網站引用主網站的內容。
l?? 通過 Reference Checking 強制網站的使用方式，防止網站內容遭受未經合法授權的「強迫瀏覽」或者「盜連」。
l?? 內建「安全防護規則設定」向導，根據實際需求與環境提供彈性與自定義安全防護規則的設定功能。
l?? 提供安全防護規則集的「版本管理」機制，并且支持「版本回溯(Rollback)」功能。
l?? 支持人工智能安全防護規則「學習模式」，提供網站系統安全防護規則設定的建議。
l?? 支持下列操作系統：Windows、Linux 與 Unix-Like 作業系統
l?? 可與「Web 應用系統源代碼自動檢測系統」所生成的安全防護規則聯動。
3.4 預期效益
通過「Web應用系統安全防火墻」與「網站源代碼弱點檢測」的部署與導入，預期達到的效益與目標：。
n? 對在線運作的網站應用程序進行防護，降低被黑風險：
通過網頁應用程序防火墻的部署，讓使用者對網站的請求，以及網站預計響應給使用者的顯示網頁，都經過「Web 應用系統安全防火墻」全程檢查與檢視其「安全性」、「合法性」與「正確性」，如有任何「非法行為」，自動「阻斷非法行為」或者「重置合法與合適的響應」，讓「使用者」與「系統管理者」都可以繼續「安心」的運作。
n? 在網站程序漏洞被黑客利用前，即可進行修補，以治本方式根除漏洞：
利用「網站程序的源代碼弱點檢測系統」，可例行對在線運作的網站程序源代碼進行掃描與檢測，以清楚存在哪些已知的弱點與漏洞，并計劃性的依據嚴重度進行修補改寫，以根除這些漏洞，提高網站的安全性。
n? 培養開發團隊編寫高安全性的網頁程序代碼與安全網站能力：
藉由網站源代碼的掃描報告解讀與程序代碼修正程序。讓開發團隊的程序開發人員，熟悉高安全性的網頁程序的編寫方法，進而養成良好的編寫與測試習慣。
?
四、內容分發網絡解決方案
4.1 內容分發網絡簡介
內容分發網絡（CDN, Content Distribution Network）服務=智能的網站鏡像+頁面緩存+流量導流。
CDN所做的，就是為互聯網上的內容提供EMS 服務，在最正確的時間用最正確的手段，把最正確的內容，推送到最正確的地點（訪問客戶），能夠幫助用戶解決分布式存儲、負載均衡、網絡請求的重定向和網站內容管理等問題。其目的是通過在現有的Internet 中增加一層新的網絡架構，將網站的內容發布到最接近用戶的網絡“邊緣”，使網站訪問用戶可以就近取得所需的網頁內容，解決 Internet網絡擁塞狀況、提高用戶訪問網站的響應速度。從技術全面解決由于網絡帶寬小、用戶訪問量大、網點分布不均而產生的用戶訪問網站響應速度慢的根本原因。
CDN 網絡營造了一個網絡運營環境，不僅能夠提供以網絡加速為基礎的系列服務，包括針對網頁、流媒體、文件傳輸、文件播放等內容提供加速，還能提供一些相關的增值服務以更有效地滿足客戶在這些應用方面的需求。
?
| ? | |
| ? | ? |
?
4.2 ??? CDN服務功能
眾所周知，互聯網的訪問速度取決于眾多的因素，包括Internet網絡傳輸質量、國內南北互聯互通問題、網站服務器性能、網站出口帶寬、網頁程架構和網頁內容類型等等。CDN網頁加速產品采用全球智能域名解析系統和高速緩存等專業技術，通過遍布全球的CDN 網絡把網頁內容分發到離網民最近的邊緣節點上，繞過國內以及跨國的傳輸擁塞影響，突破源站出口帶寬和性能屏障，訪問用戶可以從最適合的節點上獲得所需的內容，從而提高網站的訪問速度和質量。CDN 網頁加速產品支持SSL 加密，網頁壓縮，防盜鏈等功能：
n? 網頁壓縮功能：
?
| ? | |
| ? | ? |
支持網站本身的壓縮功能，同時能夠幫助未實現壓縮功能的網站提供壓縮服務，通過壓縮數據大小的改變，減少數據傳輸的時間，節省傳輸的帶寬，使頁面顯示速度自然提高。
?
n? 防盜鏈功能：
基于時間或者用戶IP 對URL 進行加密和驗證，幫助網站防止盜鏈現象。
n? 地域化內容服務功能：
根據訪問用戶的地域不同，將用戶的訪問請求分配到相應的CDN 節點上進行響應，從而為來自不同地域用戶提供針對該地域投放的特色內容，使得網站內容更加有針對性，實現個性化服務。
?
4.3? CDN服務特點
n? 安全的分發內容
?
| ? | |
| ? | ? |
CDN 節點前端都有可以抵御幾十萬級別DDoS 攻擊的設備，智能的全域負載均衡系統會根據攻擊路線改變用戶訪問目的地，保障用戶訪問不受攻擊影響。在整個分發網絡中除了網絡層有加密校驗機制，分發的文件會攜帶特定的加密碼，在傳送到最終目的地后進行校驗完畢后確認文件在傳輸過程中沒有缺失和修改，返回給中央分發服務系統安全到達的信息，且服務器采用專有OS 架構，即使遭到攻擊黑客也無法篡改用戶內容，保證分發內容的安全性和完整性。
?
n? 完善的日志分析
完善的日志分析功能，可以根據用戶個性需求，制定多重樣式的日志分析報告，包括用戶訪問行為分析、用戶來源地分析、網站點擊率分析等。并可以提供自動報表生成。
n? 網站流量及時報告
提供在線的瀏覽訪問量接口，使用戶隨時了解網站運轉狀況。
n? 網站異常告警
當網站發生非正常訪問量激增或網站源不可達時，會及時發送EMAIL到用戶信箱告知狀況并及時電話通知，使得網站安全可靠。
n? 網站鏡像
可以提供用戶網站異地鏡像功能，保證源站發生狀況后，可以借用CDN節點上的網站為用戶提供暫時的頁面訪問服務。
n? 網站頁面訪問性能優化
降低源站對高帶寬的需求，并減低源站服務器的訪問壓力。
五、負載均衡解決方案
CDN服務為訪問用戶提供更快的網站訪問速度，并降低源站的訪問壓力。而源站本地則可以采用服務器負載均衡（SLB, Server Load Balance）技術方案進一步降低源站的訪問中斷風險。更完善的負載均衡方案是采用廣域負載均衡（GLSB, Global Server Load Balance）技術為應用網站提供不同地域的主用/備用站點架構，
?
?
| ? | |
| ? | ? |
5.1 服務器負載均衡
如上圖示，假設在Internet 上提供兩個服務，分別為World Wide Web 服務(192.168.10.1)與E-commerce 服務(192.168.10.2)，而今我們在防火墻與交換機之間加入了SLB，此設備在OSI/ISO 七層架構中屬于三到七層的設備，因此可以整合不同平臺、新舊不同的服務器，另外、服務器也由一臺增加至三臺，我們稱為服務器農場(Server Farm), 并且將原本屬于服務器的IP 地址移到SLB 設備上，對使用者而言依然是存取此IP 上的服務，沒有改變。因此，必須指定另外一個網段的IP 給原來的服務器使用。此時，SLB 設備除對外提供服務，對內做到下列的功能：
n? 網絡地址轉換(Network Address Translation, NAT)：
利用此技術將內部的虛擬IP 對應到外部的真實IP(視提供的服務而定，在此例中有二個IP 需做NAT)，如此一來便可以解決用一個IP 來代替許多不同的IP 的問題。
n? 有效分配負載流量：
如何將由Internet 上的流量分配到后端的服務器上，其中包含了那一臺服務器該負責較多的工作，或是一視同仁的照次序分配而不考慮效能等因素，我們稱為負載平衡模式(Load Balance Mode)。
n? Health check 機制：
為了使SLB 設備可以有效掌控后端服務器的狀況，必須定期自動檢查服務器的運作情形，以免發生將使用者數據請求引導至發生故障或是過于忙碌的服務器上的情形。
n? Fail-Over 機制：
一旦SLB 架構建置完成，SLB 設備便成為非常重要的一個網絡節點。一旦發生故障，整個服務便會中斷，因此備援是非常重要的課題，理想的備援機制是在完全不影響使用者的前提下完成取代故障設備并提供服務的工作，一般我們也稱之為高可靠度(High Availability)。
?
5.2 廣域負載均衡
廣域負載均衡（GSLB，Global Server Load Balance）是一種將SLB的概念擴展到廣域范圍的技術，與SLB在一個單獨的節點上為一組服務器提供負載均衡服務不同，GSLB提供了一種對多個不同地域的服務器群(多個節點)提供負載均衡的服務，在實現上可以分為兩個方面，一方面是如何實現將用戶的請求指向到選定的節點上，一方面是研究如何確定最佳的站點。GSLB服務可以對分布在不同地域的多個源站服務器群提供廣域負載均衡服務，采用DNS解析的方式來實現用戶訪問重定向，同時采用智能策略確定最佳源站點，提高了服務的可用性和系統性能。
?
原理說明：
廣域負載均衡在DNS解析階段實現：
1）客戶端針對一個域名（Domain）發送一個DNS請求。
2）廣域負載均衡由一系列算法返回一個最優site的IP（延時最小、距離最近等）。
3）客戶端向此IP發起連接請求。
4）當客戶端向某IP發起訪問連接請求時，執行（本地）服務器負載均衡（SLB），負載均衡設備根據最優算法選擇服務器和相應的服務轉發請求，如上圖所示。
?
5.3 關鍵功能和特點
n? Web交換
完全支持URL交換，根據URL和HTTP信息分配流量。每個 URL 都可以重定向到某服務器，或在多個服務器之間進行負載均衡，從而提供優化的Web交換性能。根據URL文本中包含的信息，可以保持客戶持續性，從而保證內容的個性化。
n? 通過負載均衡優化服務器資源
支持的負載均衡演算法至少包含，
‐? 輪詢 (Cyclic)
‐? 最少用戶數 (Least users)
‐? 最少數據包數 (Least packets)
‐? 最少字節數 (Least bytes)
‐? 最快回應時間 (Fasted Response Time)
‐? SNMP定制 (SNMP customized)
n? 健康狀況檢查
可以監視服務器在IP、TCP、UDP、應用和內容等所有協議層上的工作狀態。如果發現故障，訪問用戶即被透明地重定向到正常工作的服務器上。
n? 完全的容錯與冗余
雙機備援架構方式提供設備間的完全容錯，以確保網絡最大的可用性。兩個設備通過網絡相互檢查各自的工作狀態，為其所管理的應用保障完全的網絡可用性。它們可工作于‘主用-備用’模式或‘主用-主用’模式，在‘主用-主用’模式下，因為兩個設備都處于工作狀態，從而最大限度地保護了投資。并且所有的訪問會話信息都可在設備間進行鏡像，從而提供透明的冗余和完全的容錯，確保在任何時候用戶都可以獲得網站訪問的最佳服務。
n? 通過正常退出服務保證穩定運行
當需要進行服務器升級或系統維護時，負載均衡設備可保證穩定的服務器退出服務以避免網站訪問中斷。當選定某臺服務器要退出負載均衡服務后，新的訪問連接將不會被指向該服務器。
n? 應用安全
‐ DDoS保護：識別和保護應用基礎架構不受DoS/DDoS攻擊。這種保護已超越了其他供應商采用的傳統SYN cookie技術所提供的保護。
‐ 入侵過濾：通過在惡意蠕蟲和病毒進入應用服務器前進行識別并拒絕，保護應用服務器不受侵襲。包檢測和過濾功能（包括對加密流量進行檢測）可支持管理員制定政策來保護系統不受這些攻擊。
‐ SSL加密：應用內容在傳輸過程中都受加密保護，通過卸載服務器復雜的加密任務將應用處理能力發揮到了極致。該功能使管理員能保護敏感應用內容的安全，使其擺脫被竊取及被濫用的潛在威脅。
n? 旁路建構方式，保障原有網絡結構
負載均衡設備可選擇以旁路方式連接至網站系統，降低Web應用交付使用的延宕風險。
?
六、應急響應服務體系
6.1 事件分類與分級
事件的分類分級，用于信息安全事件的防范與處置，為事前準備、事中應對、事后處理提供一個整體事件防范與處置的基礎。
6.1.1 事件分類
根據信息安全事件發生的原因、表現形式等，可將各種信息安全事件歸納為六大類。
1)??? 惡意程序事件：
包括 計算機病毒事件、蠕蟲事件、木馬事件、僵尸網絡事件、攻擊程序事件、網頁內嵌惡意代碼事件和其它有害程序事件等7個第二層分類。
僵尸網絡是指網絡上受到黑客集中控制的一群計算機，它可以被用于伺機發起網絡攻擊，
2)??? 網絡攻擊事件：
包括 拒絕服務攻擊事件、后門攻擊事件、漏洞攻擊事件、網絡掃描竊聽事件、網絡釣魚事件、干擾事件和其他網絡攻擊事件等7個第二層分類。
3)??? 信息內容安全事件：
包括 網頁篡改、偽造網站等2個第二層分類。
4)??? 設備設施故障：
是指由于網站系統自身故障、外圍保障設施故障或人為使用非技術手段而導致的信息安全事件。
5)??? 災害性事件：
是指由于不可抗力對信息系統造成物理破壞而導致的信息安全事件。
6)??? 其他信息安全事件：
指不能歸為以上5個基本分類的信息安全事件。
6.1.2 事件分級
對信息安全事件的分級可參考下列三個要素：信息系統的重要程度、系統損失和社會影響。系統損失是指由于信息安全事件對信息系統的軟硬件、功能及數據的破壞，導致系統業務中斷，從而給事發組織和國家所造成的損失，其大小主要考慮恢復系統正常運行和消除安全事件負面影響所需付出的代價。
1)??? 重大事件（Ⅰ級）
指能夠導致嚴重影響或破壞的信息安全事件，使重要信息系統遭受重大的系統損失，即造成系統長時間中斷或癱瘓，使其業務處理能力受到極大影響，或系統關鍵數據的保密性、完整性、可用性遭到破壞，恢復系統正常運行和消除安全事件負面影響所需付出的代價巨大，對于事發組織是無可承受的；或使重要信息系統遭受特別重大的系統損失。
2)??? 較大事件（Ⅱ級）
指能夠導致較嚴重影響或破壞的信息安全事件。使重要信息系統遭受較大的系統損失，即造成系統中斷，明顯影響系統效率，使重要信息系統或一般信息系統業務處理能力受到影響，或系統重要數據的保密性、完整性、可用性遭到破壞，恢復系統正常運行和消除安全事件負面影響所需付出的代價較大，但對于事發組織是可以承受的；或使重要信息系統遭受重大的系統損失、一般信息信息系統遭受特別重大的系統損失。
3)??? 一般事件（Ⅲ級）
一般事件是指能夠導致較小影響或破壞的信息安全事件，會使重要信息系統遭受較小的系統損失，即造成系統短暫中斷，影響系統效率，使系統業務處理能力受到影響，或系統重要數據的保密性、完整性、可用性遭到影響，恢復系統正常運行和消除安全事件負面影響所需付出的代價較小。
6.1.3 預警服務事件嚴重等級
透過網站內、外網自動監控手段并輔以人工測試方式，可將前文所列的各類事件進行嚴重等級劃分，說明如下：
| 等級 | 分類等級說明 | 相關事件 | 事件通告時效要求 |
| Ⅰ級 | 屬于重大安全事件 | 1.掛馬 2.惡意代碼 3.跨站腳本 4.病毒事件 5.網頁篡改 6.域名挾持 7.DDoS攻擊 8.釣魚/偽造網站 9.長時間網站無法訪問 | 立即通報網安辦，并配合網站管理員及運營商進行事件緊急響應處理及追蹤。 |
| Ⅱ級 | 屬安全隱患性的較大事件 | 1.可疑開放端口 2.SQL注入漏洞 3.掃描發現的系統及Web應用漏洞。 | 一個工作日內完成詳細安全風險評估報告及解決方案提交網站管理員，并配合網站管理員對漏洞進行安全加固服務。 |
| Ⅲ級 | 屬一般告警事件，此類事件發生時，對網站系統運行的影響較小或影響性是短暫的 | 1.網站出現瞬間中斷 2.域名解析故障 | 持續觀察并記錄發現問題的時間與不同癥狀，每日以文檔記錄形式發送通報網站管理員。 |
?
6.2 應急響應服務體系
應急響應服務體系由上海絡安的上海世博會信息安全保障應急響應技術處置組專家成員、各網站管理員、現場維護人員及第三方網站開發人員組成。
網站應急響應流程主要分為：分析確認、啟動應急運行，故障修復、恢復運行、詳細備案。
1、分析確認：
網站故障可分為4大類：主機設備不可用、系統不可用、遭受黑客攻擊、網頁被篡改。分析判斷網站故障屬于哪一類。
2、啟動應急運行：
切換網站到應急運行狀態。避免停止服務。
對于主機設備不可用、啟動備用服務器。
對于軟件系統不可用、停止故障網站應用，啟動備份網站內容。
遭受黑客攻擊、網頁被篡改，停止故障網站應用，啟動備份網站內容。
3、故障修復：
確認故障原因后，迅速制定故障修復方案，判斷故障的嚴重程度和恢復時間。
對于故障原因為主機設備不可用，在1小時內能修復的，聯系設備服務商協同修復。如果發生故障的服務器在2小時內不能修復，啟用備用服務器。
對于故障原因為軟件系統不可用，在1小時內能修復的，安全管理員協同系統管理員、數據庫管理員進行系統修復；如果發生故障的服務器在2小時內不能修復，啟用備用服務器。
對于故障原因為遭受黑客攻擊，采用以下步驟處理：
對于故障原因為網頁被篡改采用以下步驟處理：
4、恢復運行：
在確認故障排除之后，可恢復系統運行，如果啟動了備用服務器，應將服務器切換到原來的數據庫服務器。
5、詳細備案：
系統恢復運行后，網絡與信息安全管理員應會同站點管理員將本次網站故障的處置過程，包括故障發生時的現象、處理過程及所采取的技術手段、結果等做出詳細的文字記錄。
6、演練及維護
為了提高應急處理的速度，提高應急響應工作組成員對蠕蟲處理的熟練程度，應定期對預案進行演練。
?
轉載于:https://www.cnblogs.com/duanxz/p/4133391.html
總結
以上是生活随笔為你收集整理的网站系统安全防护体系建设方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 利用Android NDK编译lapac
- 下一篇： 常识：佛前三炷香是什么意思