證券行業應用安全架構設計實踐

一、前言

根據Freebuf《2020-2021金融行業網絡安全研究報告》顯示，隨著越來越多的金融機構進行數字化轉型，信息化、網絡化已成為現代金融行業的重要特征。與此同時，金融行業的網絡安全風險不斷累積，金融安全防護面臨前所未有的威脅挑戰。Web安全漏洞依舊是最主流的漏洞類型，熱門漏洞有XSS、SQL注入、敏感信息泄露、未授權訪問、弱口令、遠程代碼執行、任意文件讀取、邏輯漏洞等，暴露出應用系統在安全開發實踐方面的欠缺。應用系統上線后漏洞修復往往要耗費較長時間和較高的成本。

在實戰攻防演練中，也經常暴露出很多應用層問題，如高危框架或中間件、第三方開源組件漏洞、安全配置錯誤、設計不當、API未授權訪問等業務邏輯問題、敏感數據保護不足等。

為了盡早發現安全風險，降低漏洞修復成本，安全左移是一個趨勢。在項目早期階段進行安全架構設計，是一個系統性解決安全風險的有效方法。本文將從金融APP的實際案例入手，探討如何通過輕量級威脅建模進行應用安全架構設計。

二、安全架構

Gartner對安全架構的定義是：安全架構是計劃和設計組織的、概念的、邏輯的、物理的組件的規程和相關過程，這些組件以一致的方式進行交互，并與業務需求相適應，以達到和維護一種安全相關風險可被管理的狀態。

ISF報告中，對安全架構的定義是：安全架構是一組表示形式，描述了環境中安全組件的功能，結構和相互關系。安全組件可以根據安全架構的類型而有所不同，但通常包括安全控制措施、安全服務（例如身份驗證、訪問控制等）和安全產品（例如防火墻、入侵檢測等）。

安全人員一直面臨著挑戰：如何將業務問題、威脅、IT與構建的防御體系聯系起來？安全架構可以解決這類問題。安全架構提供了一種結構化的方法，向IT服務、應用程序和平臺添加安全控制措施，系統性地解決安全風險問題。

在安全架構的開發過程中，通常會產生許多表示形式。隨著業務安全需求轉換為安全控制措施，表示形式變得更加具體，形成了分層安全架構模型。

如何來設計安全架構，有方法論（Methodology）或者框架（Framework）作為參考。框架是一套系統的控制點和實踐的組合，關于“what”的條目組合，而方法論是一系列從起點到目標的實施步驟，關于“how”的指南。

安全架構方法論的一個典型例子是SABSA,它建立在Zachman企業架構方法論的基礎上，采用類似的結構，稱為SABSA矩陣,用于幫助描述組成安全架構的視圖和組件。還有其他一些方法論，比如Open Group的OSA和O-ESA。

安全架構框架的一個例子是NIST CSF。

NIST CSF是一個通用框架，提供了一種方法為組織定義邏輯安全架構，它讓用戶能夠識別業務活動的網絡安全風險，然后構建一個控制能力概要。

另一個方法論OSA提供了很多類架構模式、威脅目錄以及控制目錄，這個社區已經很久沒有更新了，但還是具有一定的參考價值。

三、安全設計原則

在安全架構設計中，有個很關鍵地方就是要遵循安全設計原則。安全設計原則，是在安全業界實踐中已被證明是成功的抽象概念的集合，是無數前輩經驗的總結。它告訴我們安全設計的正確做法以及為什么這么做。應用系統的設計人員應遵循這些安全設計基本原則進行威脅分析和安全方案設計，避免由于設計不當引入的安全風險，提升應用系統的安全性。

當今安全設計經典理論中，最為經典、被引用最多的是由MIT的Saltzer教授在1975年首先提出的8大安全設計基本原則，被安全業界奉為“經典安全原則”。經過業界多年的發展和總結，在原有8大經典設計原則的基礎上，又發展引申出其他一些安全原則，例如“縱深防御”、“不要輕信”、“保護薄弱環節”、“提升隱私”原則等。

應當指出的是，并非所有的安全設計原則都需要完全在一個系統中實現。有些安全設計原則本身就是相互沖突的，需要做出權衡。

四、威脅建模

安全架構設計方法，主要是通過攻擊面分析和威脅建模手段識別威脅、建立風險消減措施，最終形成安全設計方案。

攻擊面是指應用軟件任何可被人或其他程序訪問的部分，而攻擊面分析的目的是為了減少應用和數據暴露在不可信用戶面前的數量。攻擊面分析的核心是識別訪問入口及信任邊界。訪問入口就是數據流入流出的入口點，如身份認證入口點、管理頁面、傳輸接口等；信任邊界有網絡邊界，如互聯網、DMZ、核心網、辦公網，也有應用或服務邊界，其他還有主機邊界等。攻擊面分析還需要確定應用程序中的有價值的數據（例如機密、敏感、合規的）。

威脅建模是分析應用程序安全性的一種結構化方法，通過識別威脅，定義防御或消極威脅控制措施的一個過程。威脅建模主要有6個步驟：

1、識別資產。確定必須要保護的有價值的資產，如敏感數據、隱私信息等。

2、創建架構概述。目的是為了更好的理解系統架構，為辨別威脅做準備。具體就是繪制系統架構圖，包括標識子系統，信任邊界和數據流等。

3、分解應用程序。根據架構圖以及功能需求描述，對系統進行數據流分析，繪制相應的數據流圖，識別關鍵技術，信任邊界及系統的入口等。

4、威脅識別。威脅分析方法有威脅列表、攻擊樹、STRIDE方法等。比較常用的是STRIDE，STRIDE是從攻擊者的角度，把威脅劃分成6個類別，分別是Spooling（仿冒）、Tampering(篡改)、Repudiation（抵賴）、Information Disclosure（信息泄露）、Dos(拒絕服務)和Elevation of privilege(權限提升)。這6類與信息安全三要素和信息安全基本的三個屬性相關。隨著國內外對個人隱私保護重視程度加大，如果業務涉及個人信息，也需要考慮對隱私數據的保護。

5、記錄威脅。根據識別的威脅分析可以實施的緩解措施并記錄下來。

6、評估威脅。評估威脅的優先級，需要先解決最重要的威脅。可以采用DREAD風險模型進行威脅風險評級。DREAD從潛在損害、可重復性、可利用性、受影響用戶、可發現性5個方面進行評分。一旦獲得風險等級，就可以更新記錄的威脅并添加發現的等級。

威脅建模的輸出包括應用程序體系架構安全方面的文檔以及威脅的列表，最終由安全團隊輸出安全設計方案，開發人員基于安全設計方案進行系統功能設計和開發，通過設計安全（security by design）降低安全風險。

五、安全架構設計實踐

從上面威脅建模過程可以看出，流程太重，過于繁瑣，且對于人工投入要求較高，很難適應業務的敏捷快速迭代開發模式。因此在實際使用中，我們對威脅建模過程進行了優化，將安全需求分析和架構設計過程結合，設計了輕量級威脅建模，主要包括攻擊面分析、安全威脅庫及安全需求庫。

安全建設的目標，就是保護信息資產，實現信息安全三要素CIA，機密性（只有授權用戶可以獲取信息）、完整性（信息在輸入和傳輸的過程中，不被非法授權修改和破壞，保證數據的一致性）和可用性（保證合法用戶對信息和資源的使用不會被不正當地拒絕）。下面以證券機構某金融APP實際案例，講解如何通過輕量級威脅建模，進行安全架構設計。

該產品是一款投行類一體化服務平臺，支持移動APP客戶端及Web頁面，目標客戶既有企業內部人員，也有外部客戶，以及第三方機構。

對項目組進行問卷調研，目的是要了解系統的關鍵信息，為后面的攻擊面分析及威脅建模做準備。

調研問卷主要包括系統架構、使用場景、重要數據、部署方式等。其中系統架構關注技術實現方案、系統架構等；使用場景關注用戶場景、用戶群體、角色、訪問方式等；數據關注是否有敏感數據等；而部署方式關注部署架構、資產清單等。

根據系統架構圖，可以了解應用的基本結構。前端有APP，Web UI，后端采用微服務架構，且應用和第三方服務有交互；使用場景，既有外部客戶，也有內部用戶，暴露的接口有web頁面，也有Restful API；存在客戶敏感數據。從應用的部署架構，可以看到應用分布區域有互聯網、DMZ、核心網及辦公網。

根據調研問卷，可以大概了解應用系統的相關信息。本文的安全架構設計，關注的是通用安全風險，對于業務內部邏輯風險不做展開。

首先講一下本機構的網絡區域劃分：有互聯網接入區DMZ、核心生產網、辦公網、開發測試網、業務網，其他還有托管機房區、外聯業務區、客戶接入區、AWS等。

下面進行攻擊面分析。基于部署架構圖，簡單畫了數據流圖。

可以看出，外部實體，有通過互聯網APP及Web訪問的外部客戶，也有業務人員，還有IT運維人員，以及日志平臺及第三方系統。

數據流圖目的，主要是為了進行攻擊面分析。

從圖中，可以分析出系統主要攻擊面有：

• 移動APP
• Web頁面
• Restful API
• 管理頁面入口
• 業務人員訪問入口
• DUBBO微服務間調用接口
• 敏感數據
• 數據存儲，如數據庫、redis
• 第三方系統調用

這么多的攻擊面，如何識別威脅及消減風險，我們主要靠安全專家經驗、長期積累而形成的安全威脅庫。我們并沒有嚴格的區分安全需求及威脅建模，這個過程我們稱之為安全需求分析與架構設計，也就是輕量級威脅建模。根據業務場景，與安全威脅庫中威脅模式匹配，輸出安全解決方案。

針對本案例的金融APP的安全設計，選擇部分進行詳細描述。

1）結構安全。首先是系統分層，系統應該采用分層部署的結構，不同的組件按功能和重要程度分布于不同的網絡區域中。

生產環境中，需要與外網（互聯網）發生通信的主機，一般位于DMZ層，禁用在生產網的核心層與外網直接通信。應用部署在核心網，需要在DMZ部署接入層服務，禁止直接DMZ區部署nginx反向代理接入。從安全風險角度，Web服務部署于DMZ區，在DMZ區進行http協議卸載、參數過濾及協議轉換，DMZ到核心網使用tcp協議，這樣，可以防止攻擊payload直接打到核心網。運營管理后臺，業務運營人員采用專用的業務終端通過業務網進行訪問。IT人員通過堡壘機進行系統運維。后臺管理頁面禁止直接開放到辦公網訪問（因為辦公網可以訪問互聯網，員工存在被網絡釣魚導致機器被遠控風險，從而通過后臺管理頁面漏洞侵入核心網）。

系統使用的第三方組件如tomcat，應采用無安全漏洞版本。部署系統所采用的軟件也應該滿足安全性，版權合法且無安全漏洞。

2）移動安全。

a)APP代碼保護。基于目前市面上提供了很多或開源或商業的逆向分析工具，如apktool，dex2jar，baksmali等，因此攻擊者很容易就可以獲得應用的反編譯代碼，幾乎就是應用源代碼。在此基礎上，進一步分析應用中存在的安全漏洞以及業務邏輯，并進而攻擊服務端。為了提高逆向分析的門檻，可以進行代碼混淆、dex加殼、so加殼等方式對代碼進行保護。

b)APP運行時保護。對移動端應用的逆向分析還有動態調試。動態調試分為Java層和native層動態調試，通過動態調試，跟蹤應用運行行為，猜測業務邏輯；同時，通過動態調試還可以偽造或篡改請求/響應包，從而攻擊服務器端。可以在代碼中加入動態調試檢測來進行反調試，如調試器進程名檢測、ptrace檢測、xposed hook框架檢測等。

可以采用加固工具對Android APP進行加固保護，防止惡意破解、反編譯、二次打包等。國內有很多提供APP加固服務廠商，需要注意的是，加固會造成性能的損失，嚴重情況下可能造成應用崩潰，因此需要做好兼容性和健壯性測試。

c)APP第三方代碼安全。移動應用開發過程中，出于功能需求等原因，開發人員不可避免會集成一些其他第三方提供的代碼，如SDK。這些第三方代碼未經測試和評估就直接嵌入到應用中直接使用，容易出現不可預料的后果。一方面是第三方代碼的安全性未經測試，可能存在安全漏洞被攻擊者利用，從而威脅整個應用的正常使用。另一方面，第三方代碼額外實現了冗余功能或者申請多余的特權，可能造成用戶隱私信息泄露，或者一系列惡意行為。

對于此類威脅，安全設計方案是：集成第三方代碼時，開發人員應盡可能了解第三方代碼的功能，以及盡可能保證第三方代碼的安全性。需要在下載、集成、評估、更新升級四個階段都注意安全，實現必要的安全措施：從官網安全下載和使用；對代碼進行漏洞掃描，漏洞包括有常見Android應用漏洞，例如組件暴露、webview漏洞等；代碼審計，檢查第三方代碼是否實現多余功能或申請過多權限，審計是否有惡意代碼、敏感數據收集及傳輸等；升級和更新，一方面是漏洞的應急響應，對于已公布的安全漏洞有及時的響應；另一方面，更新時候需要重新檢測第三方代碼新版本的安全性。

d)APP端業務安全。為了防止APP用戶惡意注冊及薅羊毛等惡意行為，可以在APP中加入設備指紋，進行數據埋點等，將APP數據接入業務風控平臺，進行業務反欺詐。

3）Web安全。對于Web安全，關注常見的OWASP TOP 10漏洞，如注入、身份認證、敏感信息泄露、安全配置錯誤等。常見的防御措施有認證、授權、加密、審計、輸入驗證等。

4）Restful API安全。

Restful API以URI方式對外提供數據服務或功能服務。外部用戶多數情況下是程序或系統。提供的數據服務或功能服務多數情況下，是非公開的，即需要對HTTP請求來源和身份做識別與認證，再經過授權決策（訪問控制）后，提供相應的數據或執行功能。

推薦的安全設計參考有：

• 互聯網上暴露Restful API(或HTTP服務接口）時，應該加密（如HTTPS）；
• 采用appid、appkey或jwt等方式，來標識訪問者身份；
• 非公開Restful API服務，必須在每個端點上做認證和訪問控制；
• 對接口使用情況進行監控，完整記錄接口訪問日志；
• 對接口調用進行流量控制，控制規則包括最大允許應用程序接口調用并發數等，控制措施包括告警、暫停、拒絕等。

其他還要考慮的領域還有數據安全、個人隱私評估、大數據安全等，由于篇幅關系，就不做展開了。對所有攻擊面進行威脅庫匹配，最終形成的就是該產品完整的安全解決方案。在實際實施過程中，業務也會在實現安全功能的投入和安全風險間進行權衡，并不一定會實現所有的安全設計方案。

六、平臺化賦能

如今，越來越多的企業開始采用DevOps開發模式，實現價值的快速交付，也催生出來DevSecOps理念，本機構也很早就探索并落地DevSecOps實踐。在DevSecOps中，如何實現安全架構設計的快速交付？

通過自研三叉戟SDL全流程賦能平臺，自動化實現基于場景的輕量級威脅建模。

實現思路為項目組自主進行安全調查問卷的填寫，平臺基于調查問卷的業務場景，匹配安全威脅庫，關聯安全需求庫，自動化輸出安全設計方案。安全人員負責安全威脅庫及安全需求庫等的完善。

未來，可以借助人工智能及NLP等技術，實現自適應的智能化威脅建模。

七、總結

本文介紹了如何進行安全架構設計，以及輕量級威脅建模實踐，通過安全左移，從源頭管控安全風險，降低漏洞修復成本。行業機構可以參考本文的實踐，進行自身的安全架構設計探索和落地。