SSDLC實踐:安全設計評審
前言
軟件設計處于軟件工程中的核心地位,開發不管采用何種開發模式,都離不開軟件設計。當需求分析完成后進入設計階段,設計的好壞直接影響著軟件的質量。好的設計方案能夠讓團隊有一個清晰的愿景和路線圖,作為技術領導力讓整個團隊更容易協作。設計方案的制定需要多方參與,需要網絡工程師、架構師、數據庫管理員、安全等角色多方評審,確保功能需求、非功能需求和約束能夠被滿足,好的設計是開發出高質量軟件的基礎。
設計、架構與安全
從軟件開發生命周期的角度,軟件設計可以看作是從軟件需求規格說明書出發,根據需求分析階段確定的功能,設計軟件系統的整體結構、劃分功能模塊、確定每個模塊的實現算法等內容,形成軟件的具體方案,從整體到局部,從概念設計到詳細設計。軟件設計的工作包括:應用架構設計、網絡架構設計、接口設計、角色權限設計、流程設計、數據庫設計、界面設計等。
所有的架構都是設計,但并非所有設計都是架構。設計方案需要考慮到成本、許可協議、技術戰略、兼容性、用戶習慣。產品經理糾結于用戶需要什么功能,卻比較少關注非功能需求和約束,往往會模糊地給出“快、穩定、安全”的主觀要求。安全作為方案評審中的重要角色,需要評估復雜又抽象的方案,要求比較高的綜合能力,確保安全風險可防可控的情況下滿足實際業務需求。
應用架構設計
應用架構關注的是宏觀結構,其含義是把軟件從結構上分解為多個通過一定關系聯系的構件,常見的應用架構是兩層架構和三層架構。
兩層架構分為應用層和數據層,應用層承擔信息展示及邏輯處理,數據層負責數據存儲和管理。圖示如下:
三層架構分為表示層、業務邏輯層和數據層,表示層承擔信息的輸入輸出和展示,業務邏輯層承擔業務處理,數據層承擔數據的存儲和管理。圖示如下:
通常來說,三層架構比兩層架構安全,不同分層直接的訪問需要進行身份驗證,如業務邏輯層驗證表示層的用戶賬號密碼,數據層驗證業務邏輯層的數據庫賬號密碼。三層架構的業務邏輯層承擔對用戶數據和權限的校驗,合理的接口設計可以將大部分非法請求拒絕。接口設計需要考慮防重放攻擊、防數據篡改、防信息泄露、防未授權訪問、防程序化攻擊(爬蟲、條件競爭)等風險,可以通過時間戳timestap+簽名sign+token+ssl的常見技術來對接口進行安全設計。
網絡架構設計
網絡上按照區域通常分為內網、外網和DMZ區域,內網主要是辦公區、管理區、數據存儲區和專用區,比如銀行的現金業務和非現金業務需要隔離,需要設置專用區,外網主要是客戶和合作伙伴、DMZ是內外網之間的緩沖區。如下是常見的web應用網絡架構設計:
在進行安全設計時需要考慮到不同網絡區域的安全級別不同,比如DMZ區是不安全的區域,不能保存敏感業務數據,外網文件傳入內網需要進行病毒掃描,內網文件上傳到外網需要進行敏感信息檢測,另外一些特殊應用需要劃分VLAN,達到邏輯隔離的目的。
角色權限設計
應用的角色權限設計需要滿足兩個原則:最小權限和職責分離。每個角色應該有明確的職責,只能分配必要的權限,權限需細化到讀、寫、刪除、執行等具體操作,這樣可以避免過分授權。重要的操作需要分解為兩人以上執行,降低不當操作帶來的風險。比如數據錄入角色只能寫數據,數據復核角色只能讀復核的數據,不能修改。另外系統默認賬戶角色需禁用,特權賬戶角色需開啟雙因素認證,避免密碼丟失或默認密碼帶來的安全風險。
通過限制不同用戶的權限可以有效降低攻擊面。
流程設計
業務流程設計上需要避免常見的業務安全風險,如賬號注冊流程如果不對用戶的信息進行嚴格驗證可能出現羊毛黨批量注冊養號風險,登錄流程可能出現撞庫、暴力破解風險,支付流程可能出現虛假交易、洗錢套現風險,營銷活動流程可能出現黃牛屯號、薅羊毛風險。業務流程設計需要考慮到各種可能出現的場景,結合目前黑灰產的特點對薄弱環節進行加強,提高攻擊者成本。
其他設計如數據庫設計需要做好數據庫的分離,數據庫用戶權限需做好設置,避免應用系統使用root用戶訪問數據庫。界面設計需要避免一些不安全的功能界面,如執行自定義sql語句、shell命令的調試功能等。
安全設計檢查表
安全設計評審需要投入大量人力,而且周期很長,需要不斷的訪談,收集信息,項目的需求文檔,架構設計圖,流程圖等,而常見的安全設計問題是可以通過匯總形成checklist然后逐項檢查的,checklist包括身份認證、權限控制、日志處理、數據驗證、數據加密、數據簽名等檢查項,以下是部分示例:
安全設計檢查表可以幫助評審人員快速對設計方案進行檢查,但缺失針對性,無法做到個性化定制,因此只能作為過渡,還需要進一步探索更貼近業務的評審方式。
威脅建模
目前免費的威脅建模工具多數是客戶端軟件,如微軟和owasp都推出了威脅建模工具,缺點是只能單機安裝,不利于團隊協作,另外英文的威脅描述和安全控制方案很不友好,無法直接推送給產品經理和架構師做方案設計參考。
最終基于web前端技術實現了在線威脅建模,可以針對不同的業務線定制安全威脅庫和消減威脅建議庫,實現針對性的安全設計評審。這里沒有嚴格按照微軟的威脅建模方法,而是基于團隊的習慣進行應用架構、業務流程和角色權限的威脅分析,如下示例:
黃色標識資產,紅色標識威脅,綠色標識安全控制措施
應用架構威脅分析:
業務流程威脅分析:
角色權限威脅分析:
最終匯總的威脅分析結論如下:
總結
安全設計評審是SSDLC的重要環節,雖然有威脅建模工具可以輔助分析,但這些工具多是國外的,威脅庫的設計和描述對國內用戶很不友好,而且作為單獨的軟件無法與其他版本管理工具集成。將威脅建模過程進行適當改動可有效地落地安全設計評審活動,將威脅建模分析可視化、規范化,后續的安全測試環節也可以參考歷史的評審結論進行針對性測試。