商業銀行應用安全架構設計實踐
責編：gltian ｜2022-07-29 14:07:39傳統的信息安全工作通常偏向于事中或事后檢測漏洞，隨著敏捷開發工作的逐步推進，商業銀行認識到安全架構設計在實現IT降本增效方面的獨特優勢。近幾年，商業銀行逐步構建了安全架構設計工作體系，在組織人員、安全技術與管控流程方面，與企業IT架構密切協同，著力建設安全公共能力，為銀行業務快速發展保駕護航。
一、以業務為中心的工作目標
安全架構設計人員首先要了解常見的銀行業務類型，盡管銀行業務不斷推陳出新，但基本的業務流程變化不大，圖1從客戶旅程的視角針對零售類業務流程進行了抽象總結。
圖1 零售類業務流程
常見的銀行金融產品包括存款類、貸款類、匯款支付類和中間業務類等產品，日常的架構設計工作也主要圍繞與這些產品相關的業務類型。安全架構設計的目標并不是強制要求業務應用必須零風險上線，而是在提前識別風險后引入領先的安全技術能力和靈活的縱深防御體系，使得業務發展在機會和風險之間取得平衡，從而使銀行贏得客戶和市場。
二、安全架構設計價值
線上應用系統的安全事件除了可能對銀行自身及客戶造成資金損失和信息泄露外，處理安全事件的過程同樣費時費力，甚至需要對應用系統進行傷筋動骨式的整改。為了減少生產安全事件數量，在系統上線前即確保其對風險免疫至關重要。應用風險形成過程如圖2所示，安全風險管理的三要素分別是資產、威脅和脆弱性，威脅主體利用資產脆弱性使其處于風險之中。為了最大程度減少生產事件數量，減少應用開發完成后因修復應用脆弱性而帶來的大量整改工作，將安全工作左移至開發前的架構設計階段是非常有意義的。
圖2 應用風險形成過程
系統架構是指構成系統的組件及不同組件之間的關系，而安全架構貫穿于其他架構中，對不同架構視圖中的組件及其關系進行保護。安全架構和安全設計可以分別看作是企業級和系統級兩個不同層面的活動，這兩個活動之間有著密不可分的聯系。安全架構是從企業級的角度利用架構理論，基于安全技術建設可信身份，且具有鑒權及數據防護等功能的體系化的“安全武器庫”；安全設計則是從系統級的角度依據監管要求和風險要求在數據流模型中識別公共安全需求，或者將“安全武器庫”中的武器正確地應用到內部子系統之間，或者根據提煉公共能力的架構原則構建新的“武器”并擇機納入“安全武器庫”中進行統一管理、運營，從而完善安全架構。本文將安全架構和安全設計統稱為安全架構設計，安全架構設計工作至少為企業帶來以下兩個好處。
1.體系化識別安全設計缺陷，降低安全實現成本
多數安全問題是由于前期設計缺陷引發的，在架構設計階段，利用安全模型全面識別這些設計缺陷，比從漏洞測試的角度識別更具整體性，識別風險更為全面，可顯著降低后續漏洞整改的返工成本。
2.規劃建設安全公共能力，提升業務響應效率
在大多數情況下，安全需求屬于非功能性需求，天然不易被及時識別，加之安全產品往往需要外部采購，如果在項目實施后期才識別出安全需求，則會使整個項目陷入僵局。參考企業級架構原則，提前規劃建設安全技術能力中心，可保證IT建設過程能夠及時響應業務需求。
三、安全架構設計與企業架構建設
傳統的安全管理往往會演變成“運動式”工作，在監管部門檢查或發生安全事件的時候通常會要求項目組緊急或限期整改，這種方式無疑加深了安全部門與開發部門的矛盾，也無法達到長久的安全治理效果。通過融合IT架構的方法提升安全架構設計水平，一方面可推動建設公共類安全系統，以及將安全能力植入基礎類平臺；另一方面，借助架構管控，可將安全的標準化能力集成到各類應用系統中，以達到“潤物細無聲”的效果。
IT架構設計工作涉及應用資產管理、規范制定、方案評審、技術組件標準化等，這些工作都是安全架構設計的“使能器”。將安全架構設計融入企業架構工作中，將原來先開發后安全測試的項目管理方式調整為先安全架構設計再進行開發，可大幅度提升安全治理的效率。
四、安全架構設計體系
安全架構設計體系主要包括組織人員、安全技術、管控流程三個方面。組織人員方面，需明確人員分工，持續提升人員能力；安全技術方面，需實現安全能力解耦，確保安全功能的獨立性和可復用；管控流程方面，需實現安全管控流程左移，綜合管控多項安全活動，提前識別和緩解安全風險。
1.組織人員
復雜的安全架構設計并非一個團隊就可以獨立完成的，需要數據安全、IT安全、風控合規、應用架構、網絡、隱私保護、法務、運維等多個團隊協作，各參與方提前建立對基礎設施、架構設計規約、應用架構、安全分工的認知，清楚各應用的作用、適用場景、特點、接入辦法等。
實施安全架構設計的負責人應同時具備安全和架構兩方面的知識和經驗，由于業務知識比安全知識更為繁雜，因此我們傾向于對每個業務團隊中的系統設計人員進行安全培訓，幫助其掌握安全架構設計知識：一是應熟悉常用的攻擊方法與危害、規范要求、安全模型、安全技術、安全機制，加密算法；二是應熟悉特定業務、項目流程、內部技術服務，以及產品與產品之間、組件和組件之間的關系。
2.安全技術
安全功能最理想的狀態是與業務功能松耦合，具備一定的獨立性，這就需要將安全功能從業務邏輯中剝離出來。根據新思科技(Synopsys)發布的BSIMM軟件構建成熟度模型要求，不應當讓每個項目組自行實施全部的安全功能(如身份驗證、角色管理、密鑰管理、日志記錄、密碼、協議等)，而應由軟件安全小組(SSG)制定或由SSG推動他人制定，并發布可供工程技術團隊使用的安全性功能。這些公共的安全功能被稱為安全組件，項目組可受益于SSG預先批準的實施內容，而SSG則免于重復追蹤那些處于安全功能之中的細微錯誤。應用安全組件前后對比情況如圖3所示。
圖3 應用安全組件前后對比情況
安全組件可實現以下功能：一是幫助項目組聚焦業務功能開發，提升研發效率，凸顯安全技術價值；二是協助銀行快速滿足監管規范中的安全技術要求；三是協助行內安全規范落地，協助安全需求及安全方案落地；四是指導項目組快速修復常見漏洞問題，避免實現方式缺乏標準的問題，實現標準化整改。
安全組件分為技術組件和集成組件，其區別在于集成組件需要調用后端的安全服務實現安全能力，而技術組件則僅依賴自身實現安全能力。圖4為公共安全組件統一視圖。
圖4 公共安全組件統一視圖
3.管控流程
為保障安全架構設計落地，對于自研類的系統，應在系統建設初期開展安全需求分析、安全設計、安全開發、安全方案評審等安全活動。
(1)安全需求分析
傳統的信息安全分為物理安全、網絡安全、系統安全、應用安全、數據安全和業務安全等不同層次，然后再縱向切分，如軟件開發安全生命周期、運維縱深防護體系等。除了數據安全和業務安全需求對開發人員可見度較高外，其他層次安全需求的可見度并不高，需要進行安全需求分析。
實施安全需求分析最常用的方法是威脅建模，在研發團隊的安全活動中，對于一些擁有重要數據資產、安全事件影響較大、攻擊暴露面較大的系統，更應該系統地按迭代版本或定期開展威脅建模活動，保證這些系統安全需求分析的覆蓋率、及時率和有效率。銀行是強監管行業，需要定制具有金融特色的威脅建模流程(如圖5所示)。
圖5 定制化威脅建模流程
①識別干系方
銀行是業務最易實現數字化的行業之一，各類業務都需要信息系統的支持。隨著銀行IT架構成熟度的提高，通常一個業務需求會涉及多個業務應用系統，所以應提前識別干系人。干系人包括業務需求人員、業務風控人員、主辦系統開發人員、配合系統開發人員、系統對口業務人員等，對干系人正確且全面的識別是后續工作順利開展的前提條件。
②需求分析
需求分析這一步驟的輸出即繪制數據流圖，一般包括兩個方面：一是業務方面，二是技術方面。在業務方面，根據業務需求說明書梳理所有的交易清單，明確關鍵交易，并繪制數據流圖；在技術方面，需要梳理出關鍵鏈路上的所有節點應用，對每個節點應用進行安全多層次分析。
③合規研判
銀行是強監管行業，除了國家標準要求的安全規范外，還有金融行業的各類安全規范，監管規范通常會對銀行的各類業務場景給出明確指導意見，如《網上銀行系統信息安全通用規范》對電子銀行安全規范進行了明確，《商業銀行應用程序接口安全管理規范》對開放銀行等外聯類業務安全提出了指導意見。通常銀行會將這些規范解讀后形成行內的安全規范，從而提高合規研判的效率。
④威脅分析
威脅分析的第一步是確認該業務需求是否必需，如非必需建議不進行威脅分析，這樣可最大程度縮小攻擊面。針對銀行的常見業務，我們分別梳理了相關的威脅庫、需求庫、設計庫、漏洞庫和組件庫。
對于業務開發人員來說，基于數據流圖的威脅建模的技術門檻較高，建議業務開發人員在安全需求分析和安全設計時跳過前面的威脅分析步驟，直接使用安全模型，安全模型的代表是5A安全模型，具體內容如下。
- 身份認證(Authentication)：用戶主體是誰?
- 授權(Authorization)：授予某些用戶主體允許或拒絕訪問客體的權限。
- 訪問控制(AccessControl)：控制措施以及是否放行的執行者。
- 可審計(Auditable)：形成可供追溯的操作日志。
- 資產保護(AssetProtection)：資產的保密性、完整性、可用性保障。
⑤同類參考
根據同一交易在不同渠道的安全機制保持一致的安全原則，與現有同類業務場景的安全需求進行比較，保障安全需求的一致性。一方面確保現有的安全需求為我所用，避免遺漏安全需求;另一方面明確現有業務場景在安全需求方面的不足，為后續安全整改奠定基礎。
除了參考行內同類業務的安全需求之外，還可以了解同業機構中同類業務的安全控制機制，這些信息除了可對安全需求分析提供參考之外，還可以幫助安全架構設計人員與業務人員溝通該項業務需求的可行性。
⑥綜合評估
安全需求文檔初稿完成后，需要請各干系方對安全需求清單、安全需求分級結果進行討論，對需求進行取舍，最終確定安全需求文檔終稿，如果各方實在無法達成一致，可申請各方面專家進行聯合評審。
(2)安全設計
針對上述安全需求文檔進行方案設計，復用安全組件庫中的現有組件和安全設計庫中的現有方案，重點關注個性化的安全需求，主要步驟如下。
第一，重溫安全設計原則。因為大家都很熟悉常見的安全設計原則，此處不作贅述。
第二，了解現有各應用的架構信息和存量安全設計內容，包括主辦應用、關聯應用等。
第三，識別安全組件。安全架構設計的最大價值體現在組件復用上，在方案中明確識別出需要引用的安全組件，以開發人員熟悉的組件調用方式確保安全需求落地。對于無法使用安全組件滿足的安全設計項，可以復用已有的成熟的安全設計方案。
第四，參考標準安全設計模型。安全架構設計的一個很重要的原則是標準化設計。認證相關的模型如OIDC、OAuth2、CAS、SAML和Kerberos等，訪問控制相關的模型如ACL、RBAC、ABAC等，以及NIST和CIS發布的容器安全指南、IC卡密鑰設計、SpringSecurity、Shiro、RKL遠程密鑰加密、FIDO實現生物識別等都可供參考。除了業界標準外，現有安全產品的實現機制也是重要參考之一。
第五，安全機制通常對易用性、性能等特性產生負面影響，對于這些影響，如果安全團隊與業務開發團隊無法達成一致意見的話，通常也需要通過專家聯合評審確定最終的安全設計文檔。
(3)安全開發
安全開發環節是保障應用安全的最重要一環，主要包括以下兩個方面：一是對在設計環節識別出的安全組件進行集成，確保安全能力標準化；二是對沒有安全組件支撐的安全方案進行落地，并為這部分功能從應用中剝離為獨立的安全組件做好技術準備。
五、經驗總結
1.接受信息不對稱的現實
如果安全人員在與開發人員溝通的過程中不了解基本業務，則安全人員的工作較為被動，溝通效率較低，所以安全人員一方面需要了解基本業務知識，在與業務開發人員溝通的過程中盡可能少地丟失信息;另一方面，可積極對業務開發團隊中對安全感興趣的系統設計人員進行培訓，幫助他們掌握安全知識，這樣，比較簡單的安全架構設計工作可以由他們自行完成。
2.架構設計應以需求為中心而不是應用系統
銀行業務的復雜性決定了每個需求不是由一個系統獨立實現，安全架構設計人員進行需求分析時很難將所有關聯人員組織在一起開會，大多數情況下只能是與系統主管人員溝通業務需求和安全方案，所以往往會遇到對方對很多內容并不清楚的情況，極不利于架構設計工作的開展。
本文刊于《中國金融電腦》2022年第07期
來源:FCC30+