前言

軟件設計處于軟件工程中的核心地位，開發(fā)不管采用何種開發(fā)模式，都離不開軟件設計。當需求分析完成后進入設計階段，設計的好壞直接影響著軟件的質量。好的設計方案能夠讓團隊有一個清晰的愿景和路線圖，作為技術領導力讓整個團隊更容易協(xié)作。設計方案的制定需要多方參與，需要網(wǎng)絡工程師、架構師、數(shù)據(jù)庫管理員、安全等角色多方評審，確保功能需求、非功能需求和約束能夠被滿足，好的設計是開發(fā)出高質量軟件的基礎。

設計、架構與安全

從軟件開發(fā)生命周期的角度，軟件設計可以看作是從軟件需求規(guī)格說明書出發(fā)，根據(jù)需求分析階段確定的功能，設計軟件系統(tǒng)的整體結構、劃分功能模塊、確定每個模塊的實現(xiàn)算法等內容，形成軟件的具體方案，從整體到局部，從概念設計到詳細設計。軟件設計的工作包括：應用架構設計、網(wǎng)絡架構設計、接口設計、角色權限設計、流程設計、數(shù)據(jù)庫設計、界面設計等。

所有的架構都是設計，但并非所有設計都是架構。設計方案需要考慮到成本、許可協(xié)議、技術戰(zhàn)略、兼容性、用戶習慣。產品經理糾結于用戶需要什么功能，卻比較少關注非功能需求和約束，往往會模糊地給出“快、穩(wěn)定、安全”的主觀要求。安全作為方案評審中的重要角色，需要評估復雜又抽象的方案，要求比較高的綜合能力，確保安全風險可防可控的情況下滿足實際業(yè)務需求。

應用架構設計

應用架構關注的是宏觀結構，其含義是把軟件從結構上分解為多個通過一定關系聯(lián)系的構件，常見的應用架構是兩層架構和三層架構。

兩層架構分為應用層和數(shù)據(jù)層，應用層承擔信息展示及邏輯處理，數(shù)據(jù)層負責數(shù)據(jù)存儲和管理。圖示如下：

三層架構分為表示層、業(yè)務邏輯層和數(shù)據(jù)層，表示層承擔信息的輸入輸出和展示，業(yè)務邏輯層承擔業(yè)務處理，數(shù)據(jù)層承擔數(shù)據(jù)的存儲和管理。圖示如下：

通常來說，三層架構比兩層架構安全，不同分層直接的訪問需要進行身份驗證，如業(yè)務邏輯層驗證表示層的用戶賬號密碼，數(shù)據(jù)層驗證業(yè)務邏輯層的數(shù)據(jù)庫賬號密碼。三層架構的業(yè)務邏輯層承擔對用戶數(shù)據(jù)和權限的校驗，合理的接口設計可以將大部分非法請求拒絕。接口設計需要考慮防重放攻擊、防數(shù)據(jù)篡改、防信息泄露、防未授權訪問、防程序化攻擊(爬蟲、條件競爭)等風險，可以通過時間戳timestap+簽名sign+token+ssl的常見技術來對接口進行安全設計。

網(wǎng)絡架構設計

網(wǎng)絡上按照區(qū)域通常分為內網(wǎng)、外網(wǎng)和DMZ區(qū)域，內網(wǎng)主要是辦公區(qū)、管理區(qū)、數(shù)據(jù)存儲區(qū)和專用區(qū)，比如銀行的現(xiàn)金業(yè)務和非現(xiàn)金業(yè)務需要隔離，需要設置專用區(qū)，外網(wǎng)主要是客戶和合作伙伴、DMZ是內外網(wǎng)之間的緩沖區(qū)。如下是常見的web應用網(wǎng)絡架構設計：

在進行安全設計時需要考慮到不同網(wǎng)絡區(qū)域的安全級別不同，比如DMZ區(qū)是不安全的區(qū)域，不能保存敏感業(yè)務數(shù)據(jù)，外網(wǎng)文件傳入內網(wǎng)需要進行病毒掃描，內網(wǎng)文件上傳到外網(wǎng)需要進行敏感信息檢測，另外一些特殊應用需要劃分VLAN，達到邏輯隔離的目的。

角色權限設計

應用的角色權限設計需要滿足兩個原則：最小權限和職責分離。每個角色應該有明確的職責，只能分配必要的權限，權限需細化到讀、寫、刪除、執(zhí)行等具體操作，這樣可以避免過分授權。重要的操作需要分解為兩人以上執(zhí)行，降低不當操作帶來的風險。比如數(shù)據(jù)錄入角色只能寫數(shù)據(jù)，數(shù)據(jù)復核角色只能讀復核的數(shù)據(jù)，不能修改。另外系統(tǒng)默認賬戶角色需禁用，特權賬戶角色需開啟雙因素認證，避免密碼丟失或默認密碼帶來的安全風險。

通過限制不同用戶的權限可以有效降低攻擊面。

流程設計

業(yè)務流程設計上需要避免常見的業(yè)務安全風險，如賬號注冊流程如果不對用戶的信息進行嚴格驗證可能出現(xiàn)羊毛黨批量注冊養(yǎng)號風險，登錄流程可能出現(xiàn)撞庫、暴力破解風險，支付流程可能出現(xiàn)虛假交易、洗錢套現(xiàn)風險，營銷活動流程可能出現(xiàn)黃牛屯號、薅羊毛風險。業(yè)務流程設計需要考慮到各種可能出現(xiàn)的場景，結合目前黑灰產的特點對薄弱環(huán)節(jié)進行加強，提高攻擊者成本。

其他設計如數(shù)據(jù)庫設計需要做好數(shù)據(jù)庫的分離，數(shù)據(jù)庫用戶權限需做好設置，避免應用系統(tǒng)使用root用戶訪問數(shù)據(jù)庫。界面設計需要避免一些不安全的功能界面，如執(zhí)行自定義sql語句、shell命令的調試功能等。

安全設計檢查表

安全設計評審需要投入大量人力，而且周期很長，需要不斷的訪談，收集信息，項目的需求文檔，架構設計圖，流程圖等，而常見的安全設計問題是可以通過匯總形成checklist然后逐項檢查的，checklist包括身份認證、權限控制、日志處理、數(shù)據(jù)驗證、數(shù)據(jù)加密、數(shù)據(jù)簽名等檢查項，以下是部分示例：

安全設計檢查表可以幫助評審人員快速對設計方案進行檢查，但缺失針對性，無法做到個性化定制，因此只能作為過渡，還需要進一步探索更貼近業(yè)務的評審方式。

威脅建模

目前免費的威脅建模工具多數(shù)是客戶端軟件，如微軟和owasp都推出了威脅建模工具，缺點是只能單機安裝，不利于團隊協(xié)作，另外英文的威脅描述和安全控制方案很不友好，無法直接推送給產品經理和架構師做方案設計參考。

最終基于web前端技術實現(xiàn)了在線威脅建模，可以針對不同的業(yè)務線定制安全威脅庫和消減威脅建議庫，實現(xiàn)針對性的安全設計評審。這里沒有嚴格按照微軟的威脅建模方法，而是基于團隊的習慣進行應用架構、業(yè)務流程和角色權限的威脅分析，如下示例：

黃色標識資產，紅色標識威脅，綠色標識安全控制措施

應用架構威脅分析：

業(yè)務流程威脅分析：

角色權限威脅分析：

最終匯總的威脅分析結論如下：

總結

安全設計評審是SSDLC的重要環(huán)節(jié)，雖然有威脅建模工具可以輔助分析，但這些工具多是國外的，威脅庫的設計和描述對國內用戶很不友好，而且作為單獨的軟件無法與其他版本管理工具集成。將威脅建模過程進行適當改動可有效地落地安全設計評審活動，將威脅建模分析可視化、規(guī)范化，后續(xù)的安全測試環(huán)節(jié)也可以參考歷史的評審結論進行針對性測試。

當前文章：SSDLC實踐：安全設計評審
標題網(wǎng)址：http://uogjgqi.cn/article/cdsihjp.html