保險企業SDL安全平臺建設

萬強

（中國太平洋保險（集團）股份有限公司 上海市 200124）

安全開發生命周期（SDL）即SecurityDevelopment Lifecycle，是微軟提出的從安全角度指導軟件開發過程的管理模式。在傳統軟件開發生命周期的各個階段增加了一些必要的安全活動，軟件開發的不同階段所執行的安全活動也不同，每個活動就算單獨執行也都能對軟件安全起到一定作用。SDL 流程的核心理念就是將安全考慮集成在軟件開發的需求分析、設計、編碼、測試和維護等各階段。從需求、設計到發布產品的每一個階段都增加相應的安全活動，以減少軟件中漏洞的數量并將安全缺陷降低到最小程度。

伴隨著移動互聯和線上網銷銷售模式的成功應用,保險企業的線下柜面營銷固定傳統產品的銷售模式由于手機、平板電腦等移動設備介入,而實現了“網上”向客戶移動銷售線上模式的轉變,其他諸如投保、給付、變更、理賠等保險業務也通過自營網絡平臺載體，開展互聯網保險業務。此外，各類企業內部E 端移動應用的廣泛開發使用，也最大限度的利用了移動智能終端普及、5G 業務快速推廣的先決條件。如何最大程度降低上述應用在開發自研過程中的安全漏洞，是必須面對和解決的問題。

1 保險企業應用安全現狀及挑戰

1.1 保險企業應用安全漏洞的主要源自開發

企業安全漏洞以應用程序漏洞為主，企業自主開發或委托第三方開發的應用程序，相對通用版商業軟件，更易產生安全漏洞，更難發現和修復；應用漏洞主要是由應用開發人員引入，開發過程由于缺乏安全設計，容易產生編碼漏洞，如采用了第三方組件且未經安全評估，也容易帶入安全漏洞，以上都是應用安全漏洞的主要來源。

1.2 保險企業應用開發安全符合監管和業務要求

保險公司根據監管要求，通常已設立信息安全管理組織，但在應用安全開發方面，需要充分考慮和做到個人信息保護，同時，明確各方在安全開發生命周期的職責，設立管控角色和檢查點，保證開發人員在滿足業務需求時，全面有效的執行安全要求；此外，應用安全技術能力需在企業形成沉淀和傳承，形成屬于企業本身的應用開發安全能力；敏捷開發和DevOps 模式的廣泛采用，極大提升了應用的迭代和交付速度，因此，安全需求分析和設計、安全測試如何能夠盡可能在合適的節點介入，且不明顯影響交付速度是面臨的巨大挑戰。

1.3 保險企業應用開發安全面臨的技術挑戰

圖1：安全工具對開發過程覆蓋情況

圖2：安全知識庫

圖3：白盒測試工具在CI/CD 平臺的流程

應用開發安全技術要求是否明確，應用開發安全具有很強的專業性，安全技術要求首先要清晰明確可落地，如對于短信驗證碼的位數要求、發送頻率要求、服務端校驗要求、復用要求等應有具體的量化要求，便于安全人員檢查驗收；安全需求分析和設計靠個人經驗，如對于涉及個人敏感信息業務需要二次認證的安全要求，需求人員在設計時能否正確識別功能頁面是關鍵；安全編碼和開發靠個人能力，如對于“通過系統界面提交的已知的有害輸入進行過濾”的安全要求，開發人員需要完整實現易引發SQL 注入、XSS 跨站的字符過濾；安全測試水平亟待提高，企業雖然采購部署了應用黑盒掃描工具，或者代碼白盒掃描等自動化工具，但未形成統一的漏洞檢測標準、漏洞修復要求、策略優化機制，造成自動化測試的過程中的誤報過多，修復不及時，無法最大限度發揮和利用自動化工具能力。

2 保險企業應用安全開發體系建設實踐

保險企業應用安全開發體系建設的目的是為加強應用系統自身安全，提高應用系統生命周期安全性，將安全左移，減少安全漏洞及安全缺陷，降低漏洞修復成本。保險企業應用開發體系建設的思路，通過四個方面達成。從建立管理制度和流程規范體系入手，提供多樣化、自動化檢測工具，建設SDL 管理平臺作為技術支撐，將應用安全能力融合到DevOps 體系。

（1）安全管理制度和流程規范體系：從管理上定義企業應用安全體系，指導平臺建設及策略制定；

（2）安全工具和知識庫：各類安全基線、編碼規范、安全組件、安全測試用例的集合，提升開發、測試人員人軟件安全開發和測試技術能力；

（3）安全平臺：應用安全管理通過平臺固化為流程，安全要求固化為開發基線、檢測策略，實現安全管理平臺化。在企業DevOps 體系的各階段融入安全平臺及安全工具，使安全無縫介入持續集成和持續交付流程；

（4）人員技術能力：通過制度流程體系的建立，安全平臺、工具、知識庫的建立和使用，輔以安全培訓，實際提升開發測試人員的安全交付和檢測能力。

2.1 安全管理制度規范和流程體系

在安全管理制度方面，首先，制訂適用于全公司的應用開發安全管理辦法，從應用系統類型，如Web 類、微信類、移動APP 類等；從應用用戶群，面向客戶類（C 端）、面向合作伙伴（B 端）、面向內部員工（E 端）三類；從不同應用功能領域，提出明確具體的應用安全需求/要求；從安全要求實現的必要性，如強制要求是指必須實現的安全要求，增強要求是指可以根據應用場景、應用部署、涉及的信息敏感程度、采用的技術等選擇實現的安全要求。從不同維度，提出具體的應用開發安全要求。其次，定義和明確了企業各團隊在軟件開發生命周期各階段的職責分工、關鍵活動、工作要求、交付物等。在制度分類方面，至少應包含以下子類或文件：

（1）應用安全需求調研表：作為開發項目立項時，通過明確應用系統所面向用戶、系統架構、個人信息收集存儲情況、等保定級等作為輸入，確定所適用的應用安全需求/要求；

（2）應用安全需求模板：提出覆蓋各功能領域的應用安全管控要求，控制領域應至少包括標識與認證、授權與訪問控制、會話管理、數據安全、軟件容錯和異常管理、日志管理、移動APP 安全等；

（3）應用安全編碼規范：提升應用系統安全編碼能力，指導開發團隊有效進行應用系統安全編碼，控制領域至少應包括應用安全編碼規范包括身份認證、訪問控制、輸入輸出驗證、會話安全和數據安全等；

（4）應用安全測試指南：對應各項應用安全需求/要求，含技術要求、測試評價方法、預期結果。控制領域應至少包括標識與認證、授權與訪問控制、會話管理、數據安全、軟件容錯和異常管理、日志管理、移動APP 安全等；

（5）應用安全要求檢查清單：對應各項應用安全需求/要求，根據職責分工，開發、測試、安全團隊分別對各項安全需求/要求開展檢查，對于同一項安全要求，各團隊根據實際情況，可同時開展檢查，所有檢查項通過后方可上線發布。

圖4：APP 加固工具在CI/CD 平臺的流程

在安全流程體系方面，首先，為保證應用開發安全管理制度中在應用系統生命周期按照組織架構職責分工有效落實，在項目管理各階段明確定義了應用安全閉環管理流程，各階段包括以下安全活動：

（1）啟動階段：安全團隊審核安全需求調研情況，對應用系統進行初步的等保定級。根據調研情況，提出總體安全要求；

（2）計劃階段：安全團隊審核需求團隊提交的項目計劃實現的具體安全需求，檢查是否有遺漏。審核項目組提交的安全概要設計；

（3）開發/測試階段：安全團隊檢查是否完成安全漏洞測試、安全功能測試，通過訪談等方式檢查其他無法通過實際測試驗證的安全需求/要求；

（4）結項階段：安全團隊通過定期回顧項目是否有安全事件發生、監管漏洞通報等作為安全部分的項目后評估。

其次，建立成品軟件、第三方軟件引入的安全審核流程。檢查內容包括不限于是否具有允許在國內銷售的銷售許可證，是否具有國家權威檢測機構出具的檢測報告。對于信息安全類成品軟件，還需要檢查是否具有公安部銷售許可證。此外，對于具有Web 應用、移動APP 客戶端的成品軟件，開展安全測試，無高中危漏洞（或完成修復）后方可允許引入。

最后，建立并實施漏洞閉環量化考核機制，通過漏洞收集、評估、修復、復測跟蹤，持續改進形成閉環管理。考核方面對內部人員、外部合作商同時進行考核，漏洞考核指標包括資產備案情況、監管通報情況、漏洞產生數量、漏洞超期情況、重復漏洞情況等。考核情況與開發人員績效、外包商付款及準入掛鉤。

2.2 安全工具和知識庫建設

建立制度規范和流程體系的同時，需要同步開展應用安全工具的部署和建設，在開發過程的各個環節提供安全技術賦能，安全工具對開發過程的覆蓋重點在開發、測試、發布環（如圖1 所示）。

（1）開發環節：用于輔助開發人員在開發過程中檢測和發現潛在的代碼層面安全問題，提升代碼安全質量。白盒代碼掃描工具側重源代碼的安全掃描，第三方SDK 掃描工具側重檢測代碼引用的各類二進制軟件包的安全性；各類安全組件保存在制品庫中，供各開發項目組引用。

（2）測試環節：盡可能提供豐富的安全漏洞測試環境，可極大提高測試階段的漏洞檢出率。測試人員使用白盒代碼掃描工具、第三方SDK 掃描工具進行二次檢測驗證；黑盒應用掃描工具通常作為Web 類應用手工安全測試時的自動化輔助工具；APP 掃描工具用于發現移動應用是否存在二次打包、代碼反編譯等可通過加固解決的安全問題；對于推行CI/CD 平臺且采用容器化部署的保險企業來講，通過采用容器安全方案，覆蓋CI/CD平臺鏡像的構建、分發、運行各階段，包括鏡像安全(Images)，鏡像倉庫安全(registry)的安全性檢測。

（3）發布環節：應用系統上線或者發布前，投產節點配置經過基線檢查工具檢查，確保符合上線規范；通過基礎設施掃描，確保操作系統、中間件、數據庫無基礎通用漏洞；移動APP 應用在發布前，使用APP 加固工具完成安裝包加固。

建立安全知識庫，將各類安全基線配置、開發規范、安全測試用例和測試方法納入安全知識庫（如圖2 所示）。另外，建立安全培訓知識庫，提供安全基礎知識、常見漏洞原理和利用方法等，供各專業團隊人員學習提高。

2.3 應用安全平臺建設

建立安全測試管控平臺，實現內外部安全測試、攻防演練的統一接入，實現安全測試過程的集中管理，測試成果考核量化分析、可視化展示、風險管控，提升安全測試管控水平；建立漏洞管理平臺，安全漏洞跟蹤記錄從線下轉為線上閉環跟蹤。將系統上線和發布安全測試、互聯網滲透等渠道發現的漏洞統一錄入平臺，實現漏洞管理的漏洞收集、驗證評估、漏洞修復、復測跟蹤各項活動的線上跟蹤處置；建立SDL 應用安全開發管理平臺，打通研發過程各節點安全活動，構建面向軟件開發生命周期的閉環安全管理能力。將底層各類安全工具能力進行整合、抽象化和編排，推廣安全組件化等技術手段，把安全要求、安全專家能力固化為安全資產，從根本上提升開發團隊的安全交付水平。

（1）安全測試管控平臺：解決安全測試過程中面臨的問題，即安全測試人員如何管控及行為是否合規、安全測試如何量化考核。

在測試人員管控方面，使內、外部測試人員通過統一的VPN通道接入，根據用戶賬號控制測試時間，達到測試人員接入的統一管理。為降低測試過程中的意外風險，如發現高風險操作行為，還可一鍵封禁阻斷測試行為；在安全測試量化考核方面，首先對用戶接入平臺后的測試流量進行記錄、并解析HTTPS 加密流量，通過對存儲的流量進行查看和檢索，可溯源測試人員過程中的請求和響應，量化考核整體測試，包括多少人參與了測試，測試持續時間，測試目標統計，作為測試工作量和質量的量化評價依據。

（2）漏洞管理平臺：解決漏洞管理任務和數據統計線下操作，漏洞跟蹤人工統計錯誤多效率低的問題，實現高效率的漏洞線上閉環管理。

漏洞管理平臺的閉環管理體現在以下場景：應用系統新上線檢測場景，新建應用在上線前需通過安全測試，直至

漏洞全部修復后方可上線；應用系統發布檢測場景，應用系統版本發布前，需通過安全測試方可發布（特殊情況除外）；應用系統例行全量檢測場景，對于互聯網應用定期開展完整的安全測試，彌補之前發布測試可能存在的遺漏。在漏洞的跟蹤處置上，均遵循“漏洞發布、修復處置、復測、完成修復”的一系列閉環管理跟蹤流程，并按流程自動流轉任務。在漏洞處置任務的分派上，由于與公司的CIMS 系統對接，做到了可以準確的將漏洞分配給對應的處置人員。

（3）SDL 應用安全開發管理平臺：平臺用戶面向應用開發項目組和開發測試人員、應用安全管理人員。應用開發安全平臺以安全基線為核心，每條安全基線包括安全需求、威脅描述、參考實現方法、安全測試用例、安全組件等，形成了平臺的知識庫；對于底層已搭建好的安全工具由平臺統一編排調度，用戶通過平臺使用安全工具；將安全工具能力進行抽象，對于不同廠商的安全工具能力抽象統一，使用戶無須頻繁切換安全工具；安全工具能力整合后，用戶以任務確定平臺調用工具，實現對定向安全問題的交叉驗證能力。

（4）DevOps體系融合：在DevOps的開發、測試、交付等各階段，均有安全工具無縫介入。

以白盒掃描工具為例，開發團隊完成開發后，通過CICD 平臺發起代碼白盒掃描，如果存在漏洞開發團隊必須修復，

CICD 平臺自動檢測漏洞修復情況，如未修復開發團隊無法提交后續流程（如圖3 所示）。

以APP 加固和檢測工具為例，開發團隊完成移動應用開發后，通過CI/CD 平臺進行打包并提測。在進行打包前，必須選擇使用APP 加固工具，才能進行接下來的流程。完成加固后，由APP 檢測工具及人工執行漏洞測試。如檢測存在漏洞，需要修復漏洞并重新完成整套流程；如檢測不存在漏洞，可進入提測打包發布（如圖4 所示）。

2.4 人員技術能力建設

應用安全工具和平臺的賦能，都是為了優化企業應用安全人員結構，提升開發測試人員安全技能，最終達到提升應用安全交付質量的目標。安全人才培養體系作為應用開發安全體系建設的一部分，從人員安全培訓、能力考核、能力管理三個方面實現能力提升。

在人員安全編碼培訓方面，培訓內容以SDL 執行流程培訓、安全編碼培訓、安全工具使用培訓為主，開發人員至少應掌握和具備標識與認證、授權與訪問控制、會話安全、數據安全、軟件容錯和異常管理方面的安全編碼技能；在能力考核方面，圍繞培訓內容考試、崗位認證和等級評定開展；在培訓支撐上，以安全知識庫作為能力支撐，以安全實訓平臺的靶場練習、安全認證和考試作為培訓支撐。

在應用安全人才建設和團隊建設方面，對規模相對大的保險公司，應設立應用安全專業崗位，人員需具備安全需求設計、安全滲透測試能力、甚至是代碼審計能力；加強自主開發團隊的應用安全能力培養，同時輻射外包開發人員；建立持續性的安全培訓機制。

3 總結

保險企業SDL 安全體系及與之對應的安全平臺，在需求分析，設計，開發，測試及發布過程引入安全活動及安全工具，通過提升提升應用開發安全技術水平、應用安全測試管控能力、人員安全能力，達到應用漏洞提前規避及事先發現，最終降低應用安全漏洞數量。通過把監管安全要求納入應用系統開發需求，提升應用持續性合規符合能力，降低合規風險。