關于大型互聯網企業DevSecOps體系構建的總結與思考 - 網安 - 專業的網絡安全產業、社區、知識平臺

最近幾年隨著軟件供應鏈攻擊和數據安全事件的頻繁出現，企業面臨著重大的軟件供應鏈安全和數據泄露風險，這間接促使了越來越多的企業開始關注DevSecOps，并且期望借此來解決相關的安全風險。

在開始今天的分享之前，先簡單介紹一下DevSecOps的定義，這里主要采用援引于DoD（美國國防部）的一段定義，即DevSecOps實際上是一種旨在統一軟件開發、安全、運維運營的有組織的軟件工程文化和實踐。

DevSecOps is an organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec) and operations (Ops).

由于DevSecOps理念是將安全防御思維貫穿到整個軟件開發和運維運營階段，這就使得DevSecOps體系的構建變成一個可能的解決數據安全和供應鏈安全的有效途徑。今天的這篇文章主要來談談大型互聯網企業DevSecOps體系構建的總結和思考，為了方便讀者理解筆者將會以一個虛擬的公司Parana來做說明。

組織與文化

導讀：正如DoD的定義中所講，DevSecOps不是指具體的技術或者工具平臺而是一種軟件工程文化和實踐，因此對于期望構建DevSecOps體系的企業來說首先需要建設這樣的組織和文化。

早在2002年Parana公司的創始人就開始在全公司top-down推廣SOA（service-oritented architecture）文化[1]：

所有團隊必須通過服務接口公開他們的數據和功能
團隊間必須通過這些接口相互通信
不允許其他形式的進程間通信：不允許直接鏈接、不允許直接讀取另一個團隊的數據存儲、不允許共享內存模型、不允許任何后門；唯一允許的通信是通過網絡上的服務接口調用
每個團隊可以根據自己的需求使用任何技術來實現
所有服務接口，無一例外，都必須從頭開始設計為可外部化的，也就是說，團隊必須進行規劃和設計，以便能夠將接口暴露給外界的開發人員

此外，Parana公司的理念是Two-Pizza團隊[2]，即每個團隊是一個不超過兩個Pizza可以喂飽人數的最小獨立組織。團隊越小，協作越好。而協作非常重要，因為軟件發布的速度比以往任何時候都快。團隊交付軟件的能力可能是組織在競爭中脫穎而出的一個因素。設想一下需要發布新產品功能或需要修復錯誤的情況，往往都希望這盡快發生，這樣就可以有更短的上市時間。這樣的理念在某種意義上也非常契合DevSecOps的內在邏輯，每個應用的開發運維運營團隊應該是一個整體而不是割裂的組織，這樣既減少了跨組織間的溝通成本也大大提升了軟件交付的敏捷性及軟件運行的安全性。

通過在公司top-down推行SOA企業文化和Two-Pizza團隊組織形態，Parana公司具備了構建DevSecOps體系的基礎，每個Two-Pizza團隊類似于軍隊中的最小作戰單元（班），“麻雀雖小但五臟俱全”，每個團隊中基本上都配備了以下角色。

軟件開發工程師：負責軟件架構和開發
技術項目經理：負責軟件立項、周邊協作及項目管理
軟件支持工程師：負責軟件測試、運維和運營

流程與工具

導讀：有了相應的組織和文化，接下來就是如何通過流程和工具將DevSecOps的理念固化下來，并持續運作。本節將從計劃、開發、編譯與測試、發布與交付、部署與運維、監控與反饋幾個階段進行介紹。

一、計劃階段

Parana公司在計劃階段要求每個軟件項目立項后需要在應用服務安全評估系統中進行注冊，該系統會根據《數據分類分級要求》、《數據分級處理標準》、《TOP威脅風險庫》等生成應用服務風險評估問卷，通過回答問卷系統會自動根據問卷結果生成應用服務等級（Red、Orange、Yellow、Green），不同的級別對應著不同的安全要求，如：

Red / Orange ：需要有授權的安全評估人員完成應用服務的威脅建模分析并提交相應的修復方案，且必須在上線前完成內部的滲透測試
Yellow/Green：研發團隊可以自行進行威脅建模分析，不強制上線前需要完成滲透測試，但是必須提交應用服務的應急響應計劃和關鍵業務聯系人以備出現安全事件后可以及時響應和跟進修復

對于威脅建模能力的構建，Parana公司建立了安全BP威脅評估培訓與分層授權（Security Certifier Training）機制。簡而言之，就是在每個業務研發團隊中培養具備威脅建模分析能力的研發人員。通過績效考核權重（提升安全能力在研發工作中的正向考核權重）、業務主管推薦（提升安全能力在業務考核中的負向考核權重）鼓勵研發人員主動申請成為威脅建模分析專員，再舉行定期的安全技術培訓、考試及威脅建模實戰演練選出合格的威脅建模分析專員進入專家池，且對專家池中的人員每年進行能力復核和刷新，后續主要依賴專家池中的人員對Red/Orange級別的應用進行威脅建模分析和評估。

二、開發階段

Parana公司主要依賴零信任網關（midway-auth）和基于FIDO協議的硬件token的多因素認證（MFA）確保僅合法的內部研發人員可以接入到公司內的源代碼開發平臺；另外通過統一權限管理平臺（Bindle）動態管理研發人員與所有artifacts的訪問權限確保僅授權的人員可以訪問指定的內部artifacts，主要包括：

Permission Groups: 包含操作內部特定系統的權限組
Codes: 源代碼
Package s: 包含多個代碼文件的代碼包
VersionSets: 包含所需依賴關系的代碼包集合，類似于docker鏡像
Environments: 包含微服務安裝、配置、啟動所需的所有信息的集合，類似于k8s的pods
Hostclasses: 服務部署和運行的主機組，類似于k8s的nodes

公司通過內部 Code Review平臺強制要求研發的每個commit在 push之前都需要人工進行Peer Review，防止潛在惡意代碼進入主干代碼。為了實現開發的默認安全，降低已知安全風險，Parana公司花了很大力氣提升開發階段的公共安全能力：

公共安全組件：加解密模塊、統一認證鑒權模塊、憑據管理模塊
默認安全的開發框架：內置了隱私敏感數據脫敏、憑據管理、常見漏洞默認防御能力的適配各種開發語言的應用開發框架
分層分級的數據倉庫服務：滿足不同分類分級數據安全要求的統一存儲服務，可供開發團隊按需選擇，最大限度地降低因研發團隊自行設計開發而導致的安全風險

公司禁止直接使用或者引用外部代碼倉或者依賴庫，使用前必須先引入內部代碼倉，具體體現在以下幾點：

遵循”誰引入、誰負責“的原則，確定內部owner
引入前需要確保符合公司開源軟件許可政策
引入時同步三方依賴的名稱、版本等信息至軟件物料清單系統（SBOM）進行持續的漏洞監控
持續監控指定版本的三方依賴的漏洞信息，并及時通知三方依賴的內部owner更新升級

三、編譯與測試階段

Parana公司在代碼每次編譯階段都需要經過IAST/SAST/DAST的安全測試，重要應用代碼上線前還需要經過專門的滲透測試。

使用自研和商用的SAST（靜態應用安全測試）和DAST（動態應用安全測試）對自研代碼進行安全掃描和測試
使用安全組件分析（SCA）工具掃描代碼中依賴的所有三方開源組件識別已知漏洞使用流水線自動觸發二方及三方依賴庫版本升級、自動化測試
此外，根據應用服務安全風險評估的等級在上線前完成專門的應用服務滲透測試

四、發布與交付階段

Par a na公司的所有應用服務源代碼最終都會被編譯成 VersionSets（即包含了所需依賴關系的代碼包集合，類似于docker鏡像）進行發布并交付，所有過程都是由編譯引擎（Brazil）自動完成的（無人工介入），從而確保了VersionSets的完整性。研發團隊自身或者其他團隊需要使用這個應用只需要在自己的流水線上consume這個VersionSets即可[3]。以上這個過程，也可以使用持續交付平臺（Pipelines）通過配置流水線自動化完成整個交付過程：代碼push-》編譯-》測試-》部署。

五、部署與運維階段

Parana公司使用自動化部署平臺[4]（Apollo）將包含微服務安裝、配置、啟動所需的所有信息的集合的Environments自動化部署到應用服務運行的主機組Hostclasses上。

部署服務
無停機部署
健康追蹤
版本化的artifacts和回滾

上述這些過程同樣可以通過Pipelines實現自動化安全配置（Security Config）、工作負載（workload）加固與掃描、安全補丁與漏洞修復。

六、監控與反饋階段

Parana公司通過默認安全的開發框架引導應用服務自身進行應用、性能等日志收集與異常監控，針對潛在的安全異常要求研發團隊通過公共的數據收集與融合組件（Sushi）統一上報到安全運營中心處理，同時會持續對開發人員的角色及職責與被訪問代碼倉關聯度行為進行分析以識別潛在的軟件供應鏈和內部威脅者（ Insider Threat ）等風險。

實踐與安全

導讀：DevSecOps流程的各個階段中也面臨著一些常見的威脅類型，本節將重點講講Parana公司的應對策略和落地措施。

綜上，我們較詳細地解讀了Parana公司是如何構建自己的DevSecOps體系，相信對于希望構建此類體系的企業來說有一定的借鑒意義。

參考：

[1] https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/

[2] https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html

[3] https://gist.github.com/terabyte/15a2d3d407285b8b5a0a7964dd6283b0

[4] https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html

[5] AWS re:Invent 2015: DevOps at Amazon: A Look at Our Tools and Processes (DVO202): https://www.youtube.com/watch?v=esEFaY0FDKc

[6] DevOps Culture at Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg

[7] Automating safe, hands-off deployments: https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/