亚洲日本免费-啊轻点灬太粗太长了三男一女-麻豆av电影在线观看-日韩一级片毛片|www.grbbt.com

傳統(tǒng)的信息安全工作通常偏向于事中或事后檢測漏洞，隨著敏捷開發(fā)工作的逐步推進，商業(yè)銀行認識到安全架構(gòu)設(shè)計在實現(xiàn)IT降本增效方面的獨特優(yōu)勢。近幾年，商業(yè)銀行逐步構(gòu)建了安全架構(gòu)設(shè)計工作體系，在組織人員、安全技術(shù)與管控流程方面，與企業(yè)IT架構(gòu)密切協(xié)同，著力建設(shè)安全公共能力，為銀行業(yè)務(wù)快速發(fā)展保駕護航。

一、以業(yè)務(wù)為中心的工作目標

安全架構(gòu)設(shè)計人員首先要了解常見的銀行業(yè)務(wù)類型，盡管銀行業(yè)務(wù)不斷推陳出新，但基本的業(yè)務(wù)流程變化不大，圖1從客戶旅程的視角針對零售類業(yè)務(wù)流程進行了抽象總結(jié)。

圖1 零售類業(yè)務(wù)流程

常見的銀行金融產(chǎn)品包括存款類、貸款類、匯款支付類和中間業(yè)務(wù)類等產(chǎn)品，日常的架構(gòu)設(shè)計工作也主要圍繞與這些產(chǎn)品相關(guān)的業(yè)務(wù)類型。安全架構(gòu)設(shè)計的目標并不是強制要求業(yè)務(wù)應(yīng)用必須零風(fēng)險上線，而是在提前識別風(fēng)險后引入領(lǐng)先的安全技術(shù)能力和靈活的縱深防御體系，使得業(yè)務(wù)發(fā)展在機會和風(fēng)險之間取得平衡，從而使銀行贏得客戶和市場。

二、安全架構(gòu)設(shè)計價值

線上應(yīng)用系統(tǒng)的安全事件除了可能對銀行自身及客戶造成資金損失和信息泄露外，處理安全事件的過程同樣費時費力，甚至需要對應(yīng)用系統(tǒng)進行傷筋動骨式的整改。為了減少生產(chǎn)安全事件數(shù)量，在系統(tǒng)上線前即確保其對風(fēng)險免疫至關(guān)重要。應(yīng)用風(fēng)險形成過程如圖2所示，安全風(fēng)險管理的三要素分別是資產(chǎn)、威脅和脆弱性，威脅主體利用資產(chǎn)脆弱性使其處于風(fēng)險之中。為了最大程度減少生產(chǎn)事件數(shù)量，減少應(yīng)用開發(fā)完成后因修復(fù)應(yīng)用脆弱性而帶來的大量整改工作，將安全工作左移至開發(fā)前的架構(gòu)設(shè)計階段是非常有意義的。

圖2 應(yīng)用風(fēng)險形成過程

系統(tǒng)架構(gòu)是指構(gòu)成系統(tǒng)的組件及不同組件之間的關(guān)系，而安全架構(gòu)貫穿于其他架構(gòu)中，對不同架構(gòu)視圖中的組件及其關(guān)系進行保護。安全架構(gòu)和安全設(shè)計可以分別看作是企業(yè)級和系統(tǒng)級兩個不同層面的活動，這兩個活動之間有著密不可分的聯(lián)系。安全架構(gòu)是從企業(yè)級的角度利用架構(gòu)理論，基于安全技術(shù)建設(shè)可信身份，且具有鑒權(quán)及數(shù)據(jù)防護等功能的體系化的“安全武器庫”；安全設(shè)計則是從系統(tǒng)級的角度依據(jù)監(jiān)管要求和風(fēng)險要求在數(shù)據(jù)流模型中識別公共安全需求，或者將“安全武器庫”中的武器正確地應(yīng)用到內(nèi)部子系統(tǒng)之間，或者根據(jù)提煉公共能力的架構(gòu)原則構(gòu)建新的“武器”并擇機納入“安全武器庫”中進行統(tǒng)一管理、運營，從而完善安全架構(gòu)。本文將安全架構(gòu)和安全設(shè)計統(tǒng)稱為安全架構(gòu)設(shè)計，安全架構(gòu)設(shè)計工作至少為企業(yè)帶來以下兩個好處。

1.體系化識別安全設(shè)計缺陷，降低安全實現(xiàn)成本

多數(shù)安全問題是由于前期設(shè)計缺陷引發(fā)的，在架構(gòu)設(shè)計階段，利用安全模型全面識別這些設(shè)計缺陷，比從漏洞測試的角度識別更具整體性，識別風(fēng)險更為全面，可顯著降低后續(xù)漏洞整改的返工成本。

2.規(guī)劃建設(shè)安全公共能力，提升業(yè)務(wù)響應(yīng)效率

在大多數(shù)情況下，安全需求屬于非功能性需求，天然不易被及時識別，加之安全產(chǎn)品往往需要外部采購，如果在項目實施后期才識別出安全需求，則會使整個項目陷入僵局。參考企業(yè)級架構(gòu)原則，提前規(guī)劃建設(shè)安全技術(shù)能力中心，可保證IT建設(shè)過程能夠及時響應(yīng)業(yè)務(wù)需求。

三、安全架構(gòu)設(shè)計與企業(yè)架構(gòu)建設(shè)

傳統(tǒng)的安全管理往往會演變成“運動式”工作，在監(jiān)管部門檢查或發(fā)生安全事件的時候通常會要求項目組緊急或限期整改，這種方式無疑加深了安全部門與開發(fā)部門的矛盾，也無法達到長久的安全治理效果。通過融合IT架構(gòu)的方法提升安全架構(gòu)設(shè)計水平，一方面可推動建設(shè)公共類安全系統(tǒng)，以及將安全能力植入基礎(chǔ)類平臺；另一方面，借助架構(gòu)管控，可將安全的標準化能力集成到各類應(yīng)用系統(tǒng)中，以達到“潤物細無聲”的效果。

IT架構(gòu)設(shè)計工作涉及應(yīng)用資產(chǎn)管理、規(guī)范制定、方案評審、技術(shù)組件標準化等，這些工作都是安全架構(gòu)設(shè)計的“使能器”。將安全架構(gòu)設(shè)計融入企業(yè)架構(gòu)工作中，將原來先開發(fā)后安全測試的項目管理方式調(diào)整為先安全架構(gòu)設(shè)計再進行開發(fā)，可大幅度提升安全治理的效率。

四、安全架構(gòu)設(shè)計體系

安全架構(gòu)設(shè)計體系主要包括組織人員、安全技術(shù)、管控流程三個方面。組織人員方面，需明確人員分工，持續(xù)提升人員能力；安全技術(shù)方面，需實現(xiàn)安全能力解耦，確保安全功能的獨立性和可復(fù)用；管控流程方面，需實現(xiàn)安全管控流程左移，綜合管控多項安全活動，提前識別和緩解安全風(fēng)險。

1.組織人員

復(fù)雜的安全架構(gòu)設(shè)計并非一個團隊就可以獨立完成的，需要數(shù)據(jù)安全、IT安全、風(fēng)控合規(guī)、應(yīng)用架構(gòu)、網(wǎng)絡(luò)、隱私保護、法務(wù)、運維等多個團隊協(xié)作，各參與方提前建立對基礎(chǔ)設(shè)施、架構(gòu)設(shè)計規(guī)約、應(yīng)用架構(gòu)、安全分工的認知，清楚各應(yīng)用的作用、適用場景、特點、接入辦法等。

實施安全架構(gòu)設(shè)計的負責(zé)人應(yīng)同時具備安全和架構(gòu)兩方面的知識和經(jīng)驗，由于業(yè)務(wù)知識比安全知識更為繁雜，因此我們傾向于對每個業(yè)務(wù)團隊中的系統(tǒng)設(shè)計人員進行安全培訓(xùn)，幫助其掌握安全架構(gòu)設(shè)計知識：一是應(yīng)熟悉常用的攻擊方法與危害、規(guī)范要求、安全模型、安全技術(shù)、安全機制，加密算法；二是應(yīng)熟悉特定業(yè)務(wù)、項目流程、內(nèi)部技術(shù)服務(wù)，以及產(chǎn)品與產(chǎn)品之間、組件和組件之間的關(guān)系。

2.安全技術(shù)

安全功能最理想的狀態(tài)是與業(yè)務(wù)功能松耦合，具備一定的獨立性，這就需要將安全功能從業(yè)務(wù)邏輯中剝離出來。根據(jù)新思科技(Synopsys)發(fā)布的BSIMM軟件構(gòu)建成熟度模型要求，不應(yīng)當(dāng)讓每個項目組自行實施全部的安全功能(如身份驗證、角色管理、密鑰管理、日志記錄、密碼、協(xié)議等)，而應(yīng)由軟件安全小組(SSG)制定或由SSG推動他人制定，并發(fā)布可供工程技術(shù)團隊使用的安全性功能。這些公共的安全功能被稱為安全組件，項目組可受益于SSG預(yù)先批準的實施內(nèi)容，而SSG則免于重復(fù)追蹤那些處于安全功能之中的細微錯誤。應(yīng)用安全組件前后對比情況如圖3所示。

圖3 應(yīng)用安全組件前后對比情況

安全組件可實現(xiàn)以下功能：一是幫助項目組聚焦業(yè)務(wù)功能開發(fā)，提升研發(fā)效率，凸顯安全技術(shù)價值；二是協(xié)助銀行快速滿足監(jiān)管規(guī)范中的安全技術(shù)要求；三是協(xié)助行內(nèi)安全規(guī)范落地，協(xié)助安全需求及安全方案落地；四是指導(dǎo)項目組快速修復(fù)常見漏洞問題，避免實現(xiàn)方式缺乏標準的問題，實現(xiàn)標準化整改。

安全組件分為技術(shù)組件和集成組件，其區(qū)別在于集成組件需要調(diào)用后端的安全服務(wù)實現(xiàn)安全能力，而技術(shù)組件則僅依賴自身實現(xiàn)安全能力。圖4為公共安全組件統(tǒng)一視圖。

圖4 公共安全組件統(tǒng)一視圖

3.管控流程

為保障安全架構(gòu)設(shè)計落地，對于自研類的系統(tǒng)，應(yīng)在系統(tǒng)建設(shè)初期開展安全需求分析、安全設(shè)計、安全開發(fā)、安全方案評審等安全活動。

(1)安全需求分析

傳統(tǒng)的信息安全分為物理安全、網(wǎng)絡(luò)安全、系統(tǒng)安全、應(yīng)用安全、數(shù)據(jù)安全和業(yè)務(wù)安全等不同層次，然后再縱向切分，如軟件開發(fā)安全生命周期、運維縱深防護體系等。除了數(shù)據(jù)安全和業(yè)務(wù)安全需求對開發(fā)人員可見度較高外，其他層次安全需求的可見度并不高，需要進行安全需求分析。

實施安全需求分析最常用的方法是威脅建模，在研發(fā)團隊的安全活動中，對于一些擁有重要數(shù)據(jù)資產(chǎn)、安全事件影響較大、攻擊暴露面較大的系統(tǒng)，更應(yīng)該系統(tǒng)地按迭代版本或定期開展威脅建模活動，保證這些系統(tǒng)安全需求分析的覆蓋率、及時率和有效率。銀行是強監(jiān)管行業(yè)，需要定制具有金融特色的威脅建模流程(如圖5所示)。

圖5 定制化威脅建模流程

①識別干系方

銀行是業(yè)務(wù)最易實現(xiàn)數(shù)字化的行業(yè)之一，各類業(yè)務(wù)都需要信息系統(tǒng)的支持。隨著銀行IT架構(gòu)成熟度的提高，通常一個業(yè)務(wù)需求會涉及多個業(yè)務(wù)應(yīng)用系統(tǒng)，所以應(yīng)提前識別干系人。干系人包括業(yè)務(wù)需求人員、業(yè)務(wù)風(fēng)控人員、主辦系統(tǒng)開發(fā)人員、配合系統(tǒng)開發(fā)人員、系統(tǒng)對口業(yè)務(wù)人員等，對干系人正確且全面的識別是后續(xù)工作順利開展的前提條件。

②需求分析

需求分析這一步驟的輸出即繪制數(shù)據(jù)流圖，一般包括兩個方面：一是業(yè)務(wù)方面，二是技術(shù)方面。在業(yè)務(wù)方面，根據(jù)業(yè)務(wù)需求說明書梳理所有的交易清單，明確關(guān)鍵交易，并繪制數(shù)據(jù)流圖；在技術(shù)方面，需要梳理出關(guān)鍵鏈路上的所有節(jié)點應(yīng)用，對每個節(jié)點應(yīng)用進行安全多層次分析。

③合規(guī)研判

銀行是強監(jiān)管行業(yè)，除了國家標準要求的安全規(guī)范外，還有金融行業(yè)的各類安全規(guī)范，監(jiān)管規(guī)范通常會對銀行的各類業(yè)務(wù)場景給出明確指導(dǎo)意見，如《網(wǎng)上銀行系統(tǒng)信息安全通用規(guī)范》對電子銀行安全規(guī)范進行了明確，《商業(yè)銀行應(yīng)用程序接口安全管理規(guī)范》對開放銀行等外聯(lián)類業(yè)務(wù)安全提出了指導(dǎo)意見。通常銀行會將這些規(guī)范解讀后形成行內(nèi)的安全規(guī)范，從而提高合規(guī)研判的效率。

④威脅分析

威脅分析的第一步是確認該業(yè)務(wù)需求是否必需，如非必需建議不進行威脅分析，這樣可最大程度縮小攻擊面。針對銀行的常見業(yè)務(wù)，我們分別梳理了相關(guān)的威脅庫、需求庫、設(shè)計庫、漏洞庫和組件庫。

對于業(yè)務(wù)開發(fā)人員來說，基于數(shù)據(jù)流圖的威脅建模的技術(shù)門檻較高，建議業(yè)務(wù)開發(fā)人員在安全需求分析和安全設(shè)計時跳過前面的威脅分析步驟，直接使用安全模型，安全模型的代表是5A安全模型，具體內(nèi)容如下。

• 身份認證(Authentication)：用戶主體是誰?
• 授權(quán)(Authorization)：授予某些用戶主體允許或拒絕訪問客體的權(quán)限。
• 訪問控制(AccessControl)：控制措施以及是否放行的執(zhí)行者。
• 可審計(Auditable)：形成可供追溯的操作日志。
• 資產(chǎn)保護(AssetProtection)：資產(chǎn)的保密性、完整性、可用性保障。

⑤同類參考

根據(jù)同一交易在不同渠道的安全機制保持一致的安全原則，與現(xiàn)有同類業(yè)務(wù)場景的安全需求進行比較，保障安全需求的一致性。一方面確保現(xiàn)有的安全需求為我所用，避免遺漏安全需求;另一方面明確現(xiàn)有業(yè)務(wù)場景在安全需求方面的不足，為后續(xù)安全整改奠定基礎(chǔ)。

除了參考行內(nèi)同類業(yè)務(wù)的安全需求之外，還可以了解同業(yè)機構(gòu)中同類業(yè)務(wù)的安全控制機制，這些信息除了可對安全需求分析提供參考之外，還可以幫助安全架構(gòu)設(shè)計人員與業(yè)務(wù)人員溝通該項業(yè)務(wù)需求的可行性。

⑥綜合評估

安全需求文檔初稿完成后，需要請各干系方對安全需求清單、安全需求分級結(jié)果進行討論，對需求進行取舍，最終確定安全需求文檔終稿，如果各方實在無法達成一致，可申請各方面專家進行聯(lián)合評審。

(2)安全設(shè)計

針對上述安全需求文檔進行方案設(shè)計，復(fù)用安全組件庫中的現(xiàn)有組件和安全設(shè)計庫中的現(xiàn)有方案，重點關(guān)注個性化的安全需求，主要步驟如下。

第一，重溫安全設(shè)計原則。因為大家都很熟悉常見的安全設(shè)計原則，此處不作贅述。

第二，了解現(xiàn)有各應(yīng)用的架構(gòu)信息和存量安全設(shè)計內(nèi)容，包括主辦應(yīng)用、關(guān)聯(lián)應(yīng)用等。

第三，識別安全組件。安全架構(gòu)設(shè)計的最大價值體現(xiàn)在組件復(fù)用上，在方案中明確識別出需要引用的安全組件，以開發(fā)人員熟悉的組件調(diào)用方式確保安全需求落地。對于無法使用安全組件滿足的安全設(shè)計項，可以復(fù)用已有的成熟的安全設(shè)計方案。

第四，參考標準安全設(shè)計模型。安全架構(gòu)設(shè)計的一個很重要的原則是標準化設(shè)計。認證相關(guān)的模型如OIDC、OAuth2、CAS、SAML和Kerberos等，訪問控制相關(guān)的模型如ACL、RBAC、ABAC等，以及NIST和CIS發(fā)布的容器安全指南、IC卡密鑰設(shè)計、SpringSecurity、Shiro、RKL遠程密鑰加密、FIDO實現(xiàn)生物識別等都可供參考。除了業(yè)界標準外，現(xiàn)有安全產(chǎn)品的實現(xiàn)機制也是重要參考之一。

第五，安全機制通常對易用性、性能等特性產(chǎn)生負面影響，對于這些影響，如果安全團隊與業(yè)務(wù)開發(fā)團隊無法達成一致意見的話，通常也需要通過專家聯(lián)合評審確定最終的安全設(shè)計文檔。

(3)安全開發(fā)

安全開發(fā)環(huán)節(jié)是保障應(yīng)用安全的最重要一環(huán)，主要包括以下兩個方面：一是對在設(shè)計環(huán)節(jié)識別出的安全組件進行集成，確保安全能力標準化；二是對沒有安全組件支撐的安全方案進行落地，并為這部分功能從應(yīng)用中剝離為獨立的安全組件做好技術(shù)準備。

五、經(jīng)驗總結(jié)

1.接受信息不對稱的現(xiàn)實

如果安全人員在與開發(fā)人員溝通的過程中不了解基本業(yè)務(wù)，則安全人員的工作較為被動，溝通效率較低，所以安全人員一方面需要了解基本業(yè)務(wù)知識，在與業(yè)務(wù)開發(fā)人員溝通的過程中盡可能少地丟失信息;另一方面，可積極對業(yè)務(wù)開發(fā)團隊中對安全感興趣的系統(tǒng)設(shè)計人員進行培訓(xùn)，幫助他們掌握安全知識，這樣，比較簡單的安全架構(gòu)設(shè)計工作可以由他們自行完成。

2.架構(gòu)設(shè)計應(yīng)以需求為中心而不是應(yīng)用系統(tǒng)

銀行業(yè)務(wù)的復(fù)雜性決定了每個需求不是由一個系統(tǒng)獨立實現(xiàn)，安全架構(gòu)設(shè)計人員進行需求分析時很難將所有關(guān)聯(lián)人員組織在一起開會，大多數(shù)情況下只能是與系統(tǒng)主管人員溝通業(yè)務(wù)需求和安全方案，所以往往會遇到對方對很多內(nèi)容并不清楚的情況，極不利于架構(gòu)設(shè)計工作的開展。

本文刊于《中國金融電腦》2022年第07期

來源:FCC30+