信息系統(tǒng)應用方針組織規(guī)劃項目安全設計規(guī)范標準

1、信息系統(tǒng)應用安全設計標準XXX公司2016.031信息系統(tǒng)應用安全設計標準 編寫目的適用范圍規(guī)范性引用文件.術語和定義概述安全設計要求6.46.5用戶（終端）安全設計. 網(wǎng)絡安全設計主機安全設計應用安全設計6.4.1 應用安全功能設計6.4.2 應用交互安全設計數(shù)據(jù)安全設計6.5.1機密性要求96.5.2完整性要求106.5.3可用性要求1091編寫目的本標準依據(jù)國家信息系統(tǒng)技術標準的要求編寫。用于指導信息系統(tǒng)設計人員進行安全設計，進而開發(fā)符合公司信息安全要求的高質量信息系 統(tǒng)2適用范圍本標準規(guī)定了公司開發(fā)的信息系統(tǒng)在設計階段應遵循的主要安全原則和技術要求。 本標準適用于本公

2、司開發(fā)的寧夏商務云系統(tǒng)安全開發(fā)過程。3規(guī)范性引用文件下列文件中的條款通過本部分的引用而成為本部分的條款。凡是注日期的引用文件，其隨后所有的修改單（不包括勘誤的內(nèi)容）或修訂版均不適用于本部分，凡是不注日期的引用文件， 其新版本適用于本部分。4術語和定義中間件 middleware是指位于硬件、操作系統(tǒng)平臺和應用程序之間的通用服務系統(tǒng)具有標準的程序接口和協(xié)議可 實現(xiàn)不同硬件和操作系統(tǒng)平臺上的數(shù)據(jù)共享和應用互操作?；赝?Rollback由于某種原因而撤銷上一次 / 一系列操作，并返回到該操作以前的已知狀態(tài)的過程。符號、代號和縮略語下列縮略語適用于本部分。HTTP HyperText Transfer

3、 Protocol 超文本傳輸協(xié)議SSL Secure Sockets Layer安全套接層協(xié)議HTTPS Hypertext Transfer Protocol over Secure Socket Layer 使用 SSL的超文本傳輸協(xié)議IPIn ternet P rotocol網(wǎng)絡之間連接的協(xié)議VPN Virtual Private Network 虛擬專用網(wǎng)絡SQL Structured Query Language 結構化查詢語言XML Exte nsible Mark up Lan guage 可擴展標記語言SFTP Secure File Transfer Protocol 安全

4、文件傳送協(xié)議MIB Man ageme nt In formation Base 管理信息庫5概述一個信息系統(tǒng)通?？梢詣澐譃榻K端用戶、網(wǎng)絡、主機、應用程序、數(shù)據(jù)這五個層次。終 端用戶是請求系統(tǒng)的訪問主體，包括終端設備或訪問用戶等；網(wǎng)絡層為信息系統(tǒng)提供基礎網(wǎng)絡訪問能力，包含邊界、網(wǎng)絡設備等元素；主機系統(tǒng)層為應用軟件、數(shù)據(jù)的承載系統(tǒng)；應用 程序層提供信息系統(tǒng)的業(yè)務邏輯控制，為用戶提供各種服務，包含應用功能模塊、接口等元素；數(shù)據(jù)層是整個信息系統(tǒng)的核心，提供業(yè)務數(shù)據(jù)和日志記錄的存儲。信息系統(tǒng)在安全防護設計過程中應從這五個層面進行針對性的設計。6安全設計要求6.1用戶（終端）安全設計a）終端安全防護是對

5、信息內(nèi)網(wǎng)和信息外網(wǎng)的桌面辦公計算機終端以及接入信息內(nèi)、外網(wǎng)的 各種業(yè)務終端進行安全防護；b）根據(jù)終端類型，將終端分為辦公計算機終端、移動作業(yè)終端、信息采集類終端三類，應 針對具體終端的類型、應用環(huán)境以及通信方式等制定適宜的終端防護措施；C）用戶（終端）安全設計應符合信息系統(tǒng)安全等級保護基本要求中華人民共和國國家 標準GB/T 22239 2008的要求。6.2網(wǎng)絡安全設計網(wǎng)絡安全設計應符合GB/T 22239 2008的要求。6.3主機安全設計主機安全設計應符合 GB/T 22239 2008的要求。6.4應用安全設計6.4.1應用安全功能設計641.1身份鑒別在身份認證方面，要求如下：a）應

6、采用合適的身份認證方式，等級保護三級及以上系統(tǒng)應至少采用兩種認證方式，認證 方式如下： 用戶名、口令認證。一次性口令、動態(tài)口令認證。證書認證。b）應設計密碼的存儲和傳輸安全策略： 禁止明文傳輸用戶登錄信息及身份憑證。 禁止在數(shù)據(jù)庫或文件系統(tǒng)中明文存儲用戶密碼。COOKIE中保存用戶密碼。并使用強密碼，在生成單向散列值過程中加入應采用單向散列值在數(shù)據(jù)庫中存儲用戶密碼， 隨機值。C）應設計密碼使用安全策略，包括密碼長度、復雜度、更換周期等。4位，隨機生成且包d）宜設計圖形驗證碼，增強身份認證安全。圖形驗證碼要求長度至少 含字母與數(shù)字的組合。e）應設計統(tǒng)一錯誤提示，避免認證錯誤提示泄露信息。f）應設

7、計帳號鎖定功能限制連續(xù)失敗登錄。g）應通過加密和安全的通信通道來保護驗證憑證，并限制驗證憑證的有效期。h）應禁止同一帳號同時多個在線。641.2授權在授權方面，要求如下:a）應設計資源訪問控制方案，驗證用戶訪問權限：根據(jù)系統(tǒng)訪問控制策略對受限資源實施訪問控制，限制用戶不能訪問到未授權的功能和數(shù)據(jù);未經(jīng)授權的用戶試圖訪問受限資源時，系統(tǒng)應提示用戶登錄或拒絕訪問。Activeb）應限制用戶對系統(tǒng)級資源的訪問，系統(tǒng)級資源包括：文件、文件夾、注冊表項、Directory對象、數(shù)據(jù)庫對象、事件日志等。IP地址進C）應設計后臺管理控制方案：后臺管理應采用黑名單或白名單方式對訪問的來源 行限制。d）應設計在

8、服務器端實現(xiàn)訪問控制，禁止僅在客戶端實現(xiàn)訪問控制。e）應設計統(tǒng)一的訪問控制機制。a?sysma n ,f） 應進行防功能濫用設計，避免大量并發(fā)HTTP請求。g） 應限制啟動進程的權限，不得使用包括“Administrator ” , “root ” , “sa” ,“ Sup ervisor ”或其它特權用戶運行應用程序或連接到網(wǎng)站服務器、數(shù)據(jù)庫、或中間件。h）授權粒度盡可能小，可根據(jù)應用程序的角色和功能分類。641.3輸入和輸出驗證在輸入和輸出方面，要求如下:a)應對所有來源不在可信范圍之內(nèi)的輸入數(shù)據(jù)進行驗證，包括：1) HTTP請求消息的全部字段，包括GET數(shù)據(jù)、POST數(shù)據(jù)、COOKIE

9、和Header數(shù)據(jù) 等。2) 不可信來源的文件、第三方接口數(shù)據(jù)、數(shù)據(jù)庫數(shù)據(jù)等。 應設計多種輸入驗證的方法，包括：1)2)3)4)5)應檢查數(shù)據(jù)是否符合期望的類型。 應檢查數(shù)據(jù)是否符合期望的長度。應檢查數(shù)值數(shù)據(jù)是否符合期望的數(shù)值范圍。應檢查數(shù)據(jù)是否包含特殊字符，如：、"、(、)、&、+、應使用正則表達式進行白名單檢查。、'、"等。服務器端和客戶端都應進行輸入驗證。1) 應建立統(tǒng)一的輸入驗證接口，為整個信息系統(tǒng)提供一致的驗證方法。2) 應將輸入驗證策略作為應用程序設計的核心元素。應對輸入內(nèi)容進行規(guī)范化處理后再進行驗證，如文件路徑、c)URL地址等，需要規(guī)范化為d

10、)標準的格式后再進行驗證。e) 應當從服務器端提取關鍵參數(shù)，禁止從客戶端輸入。f) 根據(jù)輸出目標的不同，應對輸出數(shù)據(jù)進行相應的格式化處理：向客戶端寫回數(shù)據(jù)時，對用戶輸入的數(shù)據(jù)進行 HTML編碼和URL編碼檢查，過濾特殊字符(包括HTML關鍵字以及&rn,兩個n等字符)。g) SQL注入防范：進行數(shù)據(jù)庫操作的時候，對用戶提交的數(shù)據(jù)應過濾；一等特殊字符。h) XML注入防范：當使用 XML文件格式存儲數(shù)據(jù)時，若使用Xpath和XSLT功能，必須 過濾用戶提交數(shù)據(jù)中的 / '="等字符。i) 應禁止將與業(yè)務無關的信息返回給用戶。在配置管理方面，要求如下:確保配置存儲的安全：

11、1)2)3)a)Web目錄使用配置文件，以防止可能出現(xiàn)的服務器配置漏洞導致配置文件被下載； 應避免以純文本形式存儲重要配置，如數(shù)據(jù)庫連接字符串或帳戶憑據(jù)； 應通過加密確保配置的安全，并限制對包含加密數(shù)據(jù)的注冊表項、文件或表的訪問權限；應確保對配置文件的修改、刪除和訪問等權限的變更，都驗證授權并且詳細記錄； 應避免授權帳戶具備更改自身配置信息的權限。b)c)4)5)應使用旳少特權進程和服務帳戶。應確保管理界面的安全：641.4配置管理配置管理功能只能由經(jīng)過授權的操作員和管理員訪問，在管理界面上實施強身份驗證，如使用證書，如果有可能，應限制或避免使用遠程管理，并要求管理員在本地登錄；如果需要支持遠

12、程管理，應使用加密通道，如SSL或 VPN技術。d )應避免應用程序調(diào)用底層系統(tǒng)資源。e)應單獨分配管理特權。641.5會話管理在會話管理方面，要求如下：a）登錄成功后應建立新的會話：1）在用戶認證成功后，應為用戶創(chuàng)建新的會話并釋放原有會話，創(chuàng)建的會話憑證應滿足隨機性和長度要求避免被攻擊者猜測。2）IP地址綁定，降低會話被盜用的風險。b ）應確保會話數(shù)據(jù)的存儲安全：用戶登錄成功后所生成的會話數(shù)據(jù)應存儲在服務器端，并確保會話數(shù)據(jù)不能被非法訪問。 更新會話數(shù)據(jù)時，應對數(shù)據(jù)進行嚴格的輸入驗證，避免會話數(shù)據(jù)被非法篡改。C）應確保會話數(shù)據(jù)的傳輸安全：1）用戶登錄信息及身份憑證應加密后進行傳輸。如采用CO

13、OKIE攜帶會話憑證，必須合理設置 COOKIE 的 Secure、Domai n、P ath 和 Exp ires 屬性。2）HTTP GET方式傳輸會話憑證，禁止設置過于寬泛的Domain屬性。當用戶登錄成功并成功創(chuàng)建會話后，應在信息系統(tǒng)的各個頁面提供用戶退出功能； 退出時應及時注銷服務器端的會話數(shù)據(jù)。當處于登錄狀態(tài)的用戶直接關閉瀏覽器時，應提示用戶執(zhí)行安全退出或者自動為用戶完成退出過程。應設計合理的會話存活時間，超時后應銷毀會話，并清除會話的信息。應設計避免跨站請求偽造：1）在涉及到關鍵業(yè)務操作的頁面，應為當前頁面生成一次性隨機令牌，作為主會話憑證的補充；2）在執(zhí)行關鍵業(yè)務前，應檢查用戶

14、提交的一次性隨機令牌。采取加密措施來保護數(shù)據(jù)安全時，除使用SSL/TSL加密傳輸信道，針對加密技術，應滿d）應及時終止會話：1）2）e)f)3） g）足以下設計要求：1）應采用經(jīng)國密局批準的的商密算法，并確保密鑰長度能提供足夠的安全級別。2）應確保密鑰的安全。641.6參數(shù)操作操作參數(shù)攻擊是一種更改在客戶端和Web應用程序之間發(fā)送的參數(shù)數(shù)據(jù)的攻擊，包括查詢字符串、窗體字段、cookie和HTTP標頭。主要的操作參數(shù)威脅包括：操作查詢字符串、操作窗體字段、操作cookie和操作HTTP標頭。要求如下：a）應避免使用包含敏感數(shù)據(jù)或者影響服務器安全邏輯的查詢字符串參數(shù)。b）應使用會話標識符來標識客戶

15、端，并將敏感項存儲在服務器上的會話存儲區(qū)中。C）應使用HTTP POST來代替 GET提交窗體，避免使用隱藏窗體。d）應加密查詢字符串參數(shù)。e）不要信任 HTTP頭信息。f）確保用戶沒有繞過檢查。g）應驗證從客戶端發(fā)送的所有數(shù)據(jù)。641.7異常管理這些信息將增加攻擊者發(fā)現(xiàn)異常信息一般包含了針對開發(fā)和維護人員調(diào)試使用的系統(tǒng)信息， 潛在缺陷并進行攻擊的機會。要求如下：a)應使用結構化異常處理機制。 b )應使用通用錯誤信息： 程序發(fā)生異常時，應向外部服務或應用程序的用戶發(fā)送通用的信息或重定向到特定應用網(wǎng)頁。 應向客戶端返回一般性錯誤消息。C)程序發(fā)生異常時，應終止當前業(yè)務，并對當前業(yè)務進行回滾操作

16、。d) 通信雙方中一方在一段時間內(nèi)未作反應，另一方應自動結束回話。e) 程序發(fā)生異常時，應在日志中記錄詳細的錯誤消息。641.8審核與日志用戶訪問信息系統(tǒng)時，應對登錄行為、業(yè)務操作以及系統(tǒng)運行狀態(tài)進行記錄與保存,作過程可追溯、可審計，確保業(yè)務日志數(shù)據(jù)的安全。要求如下：應明確審計日志格式，可采用如下格式：1) Syslog方式：Syslog方式需要給出 syslog的組成結構。2) Snmp方式：Snmp方式需要同時提供 MIB信息。日志記錄事件宜包含以下事件：1)2)3)4)a)審計功能的啟動和關閉。信息系統(tǒng)的啟動和停止。配置變化。訪問控制信息，比如：由于超出嘗試次數(shù)的限制而引起的拒絕登錄,

17、登錄。保證操成功或失敗的C)5)6)7)8)9)ID或引起這個事件的處理程序 事件的日期、時間(時間戳)。 事件類型。 事件內(nèi)容。事件是否成功。請求的來源(例如請求的IP地址)。用戶權限的變更。用戶密碼的變更。用戶試圖執(zhí)行角色中沒有明確授權的功能。用戶賬戶的創(chuàng)建、注銷、鎖定、解鎖。用戶對數(shù)據(jù)的異常操作事件， 包括：不成功的存取數(shù)據(jù)嘗試、 數(shù)據(jù)標志或標識被強 制覆蓋或修改、對只讀數(shù)據(jù)的強制修改、 來自非授權用戶的數(shù)據(jù)操作、 特別權限用 戶的活動。審計日志應宜包含如下內(nèi)容：ID。1)2)3)4)5)6)審計日志應禁止包含如下內(nèi)容(如必須包含，應做模糊化處理)1) 用戶敏感信息(如密碼信息等)。2)

18、 用戶完整交易信息。e)f)g)3）用戶的隱私信息（如銀行卡信息、密碼信息、身份信息等） 宜加強業(yè)務安全審計。應防止業(yè)務日志欺騙。 應保證業(yè)務日志安全存儲與訪問。WEB目錄下。1）禁止將業(yè)務日志保存到2）應對業(yè)務日志記錄進行數(shù)字簽名來實現(xiàn)防篡改。3）日志保存期限應與系統(tǒng)應用等級相匹配。642應用交互安全設計應用交互指的是不同信息系統(tǒng)之間互聯(lián)時的數(shù)據(jù)交互。信息系統(tǒng)交互應通過接口方式進行, 應避免采用非接口方式。642.1明確交互系統(tǒng)a）應確定所有和本系統(tǒng)交互的其它系統(tǒng)。 b ）應確定交互的數(shù)據(jù)類型、采用的傳輸方式。642.2接口方式安全設計a） 系統(tǒng)互聯(lián)應僅通過接口設備 （前置機、接口機、通信服務器、應用服務器等設備） 進行, 不能直接訪問核心數(shù)據(jù)庫。b）接口設備上的應用宜只包含實現(xiàn)系統(tǒng)互聯(lián)所必須的業(yè)務功能，不包含業(yè)務系統(tǒng)的所有功 能。C）其它系統(tǒng)訪問本系統(tǒng)設備宜進行接口認證。d）各種收發(fā)數(shù)據(jù)、消息的日志都應予以保存，以備審計與核對。6.5數(shù)據(jù)安全設計針對安全需求中的數(shù)據(jù)安全保護需求，應從數(shù)據(jù)的機密性保護、完整性保護、可用性保護三個層面分別進行安全設計。6.5.1機密性要求a）數(shù)據(jù)傳輸應確保保密性1）應使用加密技術對傳輸?shù)拿舾行畔⑦M行機密性保護。2）宜使用安全的傳輸協(xié)議（如： HTTP