商業銀行安全架構設計實踐
一、重申以業務爲中心的安全目標
安全架構設計人員首先要了解銀行業務，儘管銀行業務不斷推陳出新，但基本的業務流程變化不大，比如我們從客戶旅程的角度針對零售類業務總結了以下流程：
如上圖所示，其中交易包括存款類、貸款類、匯款類和中間業務類等交易，可以說我們日常安全需求分析和設計申請多數來源於上述這些類型的業務需求。安全架構設計的目標並不是要求業務零風險上線，而是通過引入領先的安全技術能力和構建靈活的縱深防禦體系，幫助業務在機會和風險中間取得平衡，最終贏得客戶和市場。
二、應用系統風險生命週期管理
線上應用系統的安全事件除可能對銀行自身及客戶造成損失外，處理安全事件的過程同樣費時費力，成本高昂。爲了減少生產事件數量，我們自然很希望在系統上線前即保證其對風險免疫。應用系統的建設過程如同養娃，而系統上線則是將娃養大成人後推向社會，最終成爲能夠修身，齊家，治國，平天下的有用之人，當然這一切的前提是其能夠屏蔽社會上的各類危害的不良影響。
圖 1 風險生命週期管理
三、安全架構設計的定義
我們的目標是保護業務安全，儘管安全架構設計在業界分享不是很多，爲了使安全工作降本增效，我們需要摸索推進安全架構設計工作。在談安全架構設計的時候我們必須考慮到實戰場景的威脅模型和安全屬性（如機密性、完整性、可用性、隱私性、真實性等等）組成的安全模型（包括下文提到的 5A 模型），脫離威脅模型和安全模型空談絕對安全幾乎毫無意義。
四、安全架構設計的價值
除了上面提到的可以實現安全工作降本增效之外，安全架構設計還有以下 2 個好處：
1. 識別體系化的結構缺陷：大多數安全問題是設計缺陷問題，通過安全架構模型全面識別這些體系化設計缺陷，比漏洞測試角度更具整體觀，識別風險更爲全面，提前減少風險敞口。
2. 識別國內外合規要求：由於銀行通常涉及跨國分行和海外業務，通過向監管機構和合作夥伴提供產品的風險管理活動的完整記錄，幫助開發團隊遵守國內或全球法律法規要求如《個人金融信息保護技術規範》、PCI DSS、GDPR 等。
五、安全架構設計概述
安全架構設計主要從組織人員、管理流程、安全技術三個方面推進工作，組織人員方面需明確人員分工，持續提升人員能力；管控流程上實現安全管控流程左移，特別是安全需求分析和安全設計；安全技術上實現安全能力解耦，確保安全功能的獨立性和可複用。
1、組織人員
在進行復雜的安全架構設計時並非一個團隊就可以獨立完成的，還需要數據安全、IT 安全、風控合規、應用架構、網絡、隱私保護、法務、運維等多個團隊協作，各參與者最好提前建立對基礎設施、架構設計規約、應用架構、安全分工的認知，清楚各應用的作用、適用場景、特點、接入辦法。對於實施安全架構設計的負責人有以下基本技術能力要求，其中第 2 條並不是安全人員的特長而是開發人員的特長，需要較長時間的工作積累：
a. 熟悉常用的攻擊方法、危害、規範要求、安全模型、安全技術、安全機制，加密算法；
b. 熟悉業務、項目流程、內部技術服務、產品與產品之間、組件和組件之間的關係；
2、管控流程
對於外部採購的系統，立項、POC 階段就開展安全需求分析和設計活動；對於自研類的系統，在系統建設初期，參照 SDL 流程，做好安全需求分析、安全設計、安全方案評審等安全活動，但因爲面臨工作多、難度大，人員少等問題、所以務必需要對需求分類分級。
安全需求分析
傳統的安全一般是分層的，物理安全、網絡安全、系統安全、應用安全、數據安全和業務安全，然後再縱向切分，如軟件開發安全生命週期、運維縱深防護體系。通常除了數據安全和業務安全需求對開發人員可見外，理論上這兩層的安全需求應該是業務需求的一部分，而其他層次的安全需求的可見度並不高，需要進行安全需求分析。
實施安全需求分析最常用的方法是威脅建模，在研發團隊的安全活動中，對於一些擁有重要數據資產、安全事件影響大、攻擊暴露面大的系統除了要進行常規的安全測試之外，更應該系統地按迭代版本或定期開展威脅建模活動，保證這些系統的安全需求分析的覆蓋率、及時率和有效率。因爲銀行是強監管行業，我們需要定製化威脅建模。
1. 識別干係方
銀行是業務最容易數字化的行業，各種業務都需要信息系統的支持，隨着銀行應用架構成熟度的提高，通常一個業務需求會涉及到多個業務應用系統。我們應提前識別干係人，干係人包括業務需求人員、業務風控人員、主辦系統開發人員、配合系統開發人員、系統對口業務人員等，對干係人的正確全面識別是後續工作順利開展的前提條件。
2. 需求分析
需求分析這一步驟的輸出就是繪製數據流圖，數據流圖這項技術本身存在的不足是：關注組件的交付是還是相對偏數據流動視角，例如釣魚等風險不能充分揭示；不能完全表達出應用系統的全部交易，只能關注重點交易；數據流會額外顯示出其他安全層引起的風險，並不僅僅是業務自身的應用安全。
針對上面這些缺點，需求分析一般包括 2 個方面，一個是業務方面，一個是技術方面，業務方面首先梳理所有的交易清單並明確是否關鍵交易，因爲不同交易的數據流可能是不一致的。技術方面我們需要梳理出關鍵鏈路上的所有節點應用，對每個節點應用進行安全多層分析，分析其層間依賴組件。
3. 合規研判
銀行是強監管行業，除了國家標準要求的安全規範外，還有金融行業的各類安全規範，監管規範通常會對銀行的各類業務場景給出了明確指導意見，如《網上銀行系統信息安全通用規範》對電子銀行安全進行了明確，《商業銀行應用程序接口安全管理規範》對開放銀行等外聯類業務安全提出了指導意見。通常銀行會將這些規範解讀後形成行內的安全規範，這樣可以提高合規研判這一步驟的效率。
4. 威脅分析
目前業內有 STRIDE、Trike、OCTAVE 等多種常見威脅分析方法論，有很多可以參考的資料，我們這裏不做詳細討論，這裏我想提醒大家的是威脅分析的第一步是確認該業務需求是否必需，如非必需建議不做，這樣可最大程度降低攻擊面。針對銀行的常見業務，我們分別梳理了相關的威脅庫、需求庫、設計庫和漏洞庫。梳理的威脅風險列表示例如下：
基於數據流圖的威脅建模對於業務開發人員來說的門檻還是比較高的，建議開發人員在安全需求分析和安全設計時跳過前面的威脅分析步驟，直接使用安全架構模型，畢竟開發人員更熟悉安全架構模型。安全模型的代表是 5A 安全模型：
身份認證（Authentication）：用戶主體是誰？
授權（Authorization）：授予某些用戶主體允許或拒絕訪問客體的權限。
訪問控制（Access Control）：控制措施以及是否放行的執行者。
可審計（Auditable）：形成可供追溯的操作日誌。
資產保護（Asset Protection）：資產的保密性、完整性、可用性保障。
我們都知道無論哪層的架構都包括三要素：職責明確的模塊或者組件、關聯關係、約束和指導原則，5A 安全模型就是對組件間的交互過程提供保護，當然這種保護是跨安全分層的。
圖 2 5A 安全模型
5. 同類參考
根據保持同一交易在不同渠道的安全機制一致的原則，與現有同類業務場景的安全需求進行相比，保障安全需求的一致性，一方面確保現有的安全需求爲我所用，避免遺漏安全需求，另一方面明確現有業務場景在安全需求方面的不足，爲後續安全整改奠定基礎。
除了參考行內同類業務的安全需求之外，我們還可以瞭解同業機構中同類業務的安全控制機制有哪些，這些信息除了對安全需求分析提供參考之外，還可以幫忙我們與業務人員溝通該項業務需求的可行性。
6. 綜合評估
安全需求文檔的初稿普通要求較爲嚴格，通過召集各干係方溝通，請大家對安全需求清單、安全需求分級結果進行討論，討論取捨哪些需求，最終確定安全需求文檔終稿，如果各方實在無法達成一致，則申請專家聯合評審。
2 安全設計
針對上述安全需求文檔進行方案設計，複用安全設計庫的中現有方案，重點關注該應用個性化的安全需求，主要步驟包括：
- 回顧安全設計原則：因爲大家都很熟悉這裏不做贅述。
2. 瞭解現有安全設計：包括主辦應用、關聯應用，如果我們對各應用的情況有所瞭解，則可以大大提高效率，通過與開發人員面對面訪談了解安全設計現狀。
3. 參考標準安全模型：安全架構設計的一個很重要的原則是標準化設計。認證相關的模型如 OIDC、OAuth2、CAS、SAML 和 Kerberos 等，訪問控制相關的模型如 ACL、RBAC、ABAC 等、NIST 和 CIS 發佈容器安全指南、IC 卡密鑰設計、SpringSecurity、Shiro、RKL 遠程密鑰加密、FIDO 實現生物識別等。除了業界標準外，目前安全產品的實現機制也是重要參考之一。
4. 串聯安全組件：安全設計的最大價值體現在解決問題上，通常安全設計方案偏向理論說明，落地過程中存在開發人員理解差異等問題，我們日常工作中應該注意收集和規劃公共安全組件，在方案中明確引用相關的安全組件，以開發人員熟悉的組件調用方式確保安全方案落地。對於無法使用安全組件滿足的安全設計項，還需要與各關聯方溝通安全功能的具體分工，以確保方案落地。
5. 安全方案評審：
除了客戶和業務的顯式安全需求外，安全機制通常對易用性、性能等特性產生負面影響，這些影響如果與業務開發團隊無法達成一致的話，通常也需要通過專家評審確定最終的安全設計文檔。
3、安全技術
安全功能最理想的狀態是與業務功能松耦合，具備相當的獨立性，這就要求將安全功能從業務邏輯中剝離出來。安全設計方案的落地離不開安全組件，根據新思科技 (Synopsys) 發佈的 BSSIM 軟件構建成熟度模型要求，不應當讓每個項目組自行實施全部的安全功能（例如，身份驗證、角色管理、密鑰管理、日誌記錄、密碼、協議等等），而應當通過 SSG (軟件安全小組)制定或由 SSG (軟件安全小組)推動他人制定併發布可供工程技術團隊使用的安全性功能來提供前瞻性的指導。這些公共的安全功能被稱爲安全組件，項目組可受益於 SSG 預先批准的實施內容，而 SSG 則免於重複追蹤那些常常處於安全功能之中的細微錯誤。
圖 3 使用安全組件前後對比
安全組件的好處有以下幾個：
1 幫助項目組聚焦業務功能開發，促進提升研發效率，突顯安全技術價值。
2 協助我行快速滿足落實和滿足監管規範中的安全技術要求。
3 協助行內安全規範落地，協助安全需求及安全方案落地。
4 指導項目組快速修復常見漏洞問題，避免實現方式缺乏標準的問題，實現源頭性整改。
我們目前梳理的應用組件視圖如下，分爲 SDK 和系統，其中系統還可以根據封裝粒度的大小分爲原子系統和組合系統：
圖 4 公共安全組件統一視圖
六、經驗教訓
1 承認雙方信息不對稱
如果安全人員在與開發人員溝通的過程中不瞭解他們的基本業務，我們安全人員其實是很被動，溝通效率低，所以我們一方面需要了解基本業務知識，這樣才能在業務人員溝通的過程中儘可能少的丟失信息，另一方面我們積極培訓業務開發團隊中對安全感興趣的人員，幫助他們掌握安全知識，這樣比較簡單的安全需求可以由他們自行完成。
2 正確理解安全左移
作爲軟件開發中心的安全人員，雖然理論上我們只需關注應用安全，但在實際操作過程中，作爲離應用系統開發人員最近的安全人員我們義不容辭的要承擔起其他安全分層中安全左移的工作。如果開發人員在上線前才知道系統的管理端與交易端需要拆分部署，顯然爲時已晚了。
3 以需求爲中心而不是以應用系統爲中心
銀行業務的複雜性決定了每個需求都不是由一個系統獨立實現，而是一個系統工程，然而我們需求分析時很難組織所有關聯繫統在一起開會，大多數只能會主辦系統的人員溝通業務需求和實現方案，所以往往會遇到對方對很多內容並不清楚的情況，這個時候我們就很難繼續下去，只能把問題提出來請他們去搞清楚再評估。
4 僅分析相對高階的安全需求
最開始踐行安全需求的時候，我們總是想希望做得很全面，於是出具一個很冗長的安全需求，希望這個安全需求一直可以傳遞到安全測試階段。這個方式理論上很好，但也喪失了重點，應該不同階段解決解決不同的安全需求，基礎的安全需求靠組件和自動化測試解決，我們應該重點關注這個業務場景中一些相對獨特的或薄弱的安全需求。
5 與開發人員形成信任
開發人員日常開發過程中一定會遇到安全相關的問題，他願意和你溝通且能幫助他們解決問題的話，雙方之間就會逐漸形成信任，信任以後在日常的溝通中開發人員的安全意識就會提高，也就會在這個項目組成爲安全的廣播員，後續就可以不失時機的安排培訓了。
6 爲啥新增業務需求不能複用存量的安全設計方案。
a. 隨着監管制度法規的完善對業務的安全性提出更高的要求，如國密算法要求；
b. 公司安全基礎設施能力不斷提升，爲業務提供的公共安全能力不斷增強，如之前由應用系統自行實現，目前由公共安全組件統一實現；
7 安全架構設計業內經驗分享少。
我們採用的思路是眼前滅火與體系建設同時推進的思路開展安全架構設計工作，在滅火期我的主要目標是提高高風險系統的覆蓋率和及時率，後續從組織人員、管控流程和安全技術等方面逐步完善體系。
（來自：金融科技人）
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/R6BiDHIoarKqzCDH7OOvoA