[[407331]]

過去幾年以來，DevSecOps已經(jīng)成為DevOps生態(tài)當中的一波熱潮，它結(jié)合了DevOps的效率優(yōu)勢，同時提高軟件安全性。但當我們靜心下來實際推行DevSecOps時，情況往往變得頗為棘手。DevSecOps并不能”一鍵啟動“，它的落地需要一系列工具與實踐的協(xié)同支持。

下面，我們來聊聊DevSecOps實現(xiàn)過程中必須考慮的主要因素，了解其中到底存在哪些障礙。

DevSecOps是什么?

從本質(zhì)上講，DevSecOps就是在根源上內(nèi)置有安全因素的DevOps。這要求我們將安全性融入需求、設計、編碼與部署階段——換句話說，納入整個DevOps管道。

舊有安全實踐往往會拖慢開發(fā)團隊的行動速度。而面對產(chǎn)品上市周期每年都在縮短的現(xiàn)實要求，軟件開發(fā)團隊必須找到一種新方法以加快自己的軟件開發(fā)速度，同時又不對安全性造成影響。DevSecOps的意義也在于此。

DevSecOps的終極目標是在安全團隊與開發(fā)人員之間架起橋梁，保證既快速、又安全地完成代碼交付。以往的孤島思維，也將由此被替代為在不同團隊之間實現(xiàn)應用安全責任分攤。

DevSecOps實踐與工具

那我們要如何把這些目標轉(zhuǎn)化為實踐?我們可以對哪些特定安全環(huán)節(jié)進行自動化，再將其集成至CI/CD管道當中?讓我們結(jié)合DevSecOps工具與實踐的現(xiàn)實情況，共同為這些問題找尋答案。

第一，漏洞掃描

掃描代碼內(nèi)的漏洞無疑是保護產(chǎn)品的第一步。而將漏洞掃描機制集成到CI/CD流程中，自然成為實現(xiàn)DevSecOps的絕佳起點。這意味著我們需要保證在交付管道中從代碼編寫到生產(chǎn)部署的各個主要階段，全面檢查代碼中是否存在漏洞。大家需要保證負責管道各個環(huán)節(jié)的不同團隊都擁有檢測代碼漏洞所需要的專業(yè)知識及技術工具。

這類技術工具主要包括檢測專有代碼內(nèi)漏洞的SAST工具，以及檢測包含已知漏洞的開源組件的SCA工具。不少SAST與SCA供應商也都提供面向CI服務器、構(gòu)建工具、存儲庫以及IDE的集成方案，能夠幫助開發(fā)人員更快發(fā)現(xiàn)問題。

第二，運行時保護

安全流程中的另一大關鍵在于運行時保護，同樣需要以DevSecOps策略的形式被集成至CI/CD管道當中。

運行時保護的本質(zhì)，在于保護軟件免受應用程序開始運行之后可能遭遇的威脅影響。盡管在傳統(tǒng)上，關于運行時安全性的討論主要集中在軟件生產(chǎn)流程，但事實證明交付管道中的早期階段同樣可能存在運行時威脅因素。即使并不存在，我們也同樣有必要及早考慮到這一安全問題，從源頭抓起減輕運行時威脅。出于這兩大基本原因，我們才應該將運行時安全納入CI/CD管道，而不再僅限于生產(chǎn)環(huán)境。

用于運行時檢測的特定工具與策略，具體取決于企業(yè)的當前業(yè)務需求。但大家至少要保證能夠監(jiān)控當前應用程序中是否存在可能與違規(guī)相關的異常行為。更重要的是，企業(yè)需要了解哪些環(huán)境變量或配置設定可能會在運行時內(nèi)產(chǎn)生安全漏洞，并制定出相應流程及時識別出此類風險。

第三，云服務供應商

向應用程序交付流程中引入安全集成的另一大重要策略，在于充分利用云服務供應商提供的安全功能。其中不少工具位于DevOps鏈的部署及部署后端，因此更多類似于傳統(tǒng)意義上的事后安全服務。但其仍然能夠在應用程序的外部防御體系中發(fā)揮重要作用——而且由于其屬于云基礎設施的固有組成部分，因此更易于實現(xiàn)自動化與系統(tǒng)化。

請注意，云服務供應商可能會默認禁用某些安全功能，或者需要進行相應配置才能起效，因此大家可能需要主動操作才能享受由此帶來的便利。

第四，標準與政策

安全標準與政策的制定在很大程度上仍然只能以手動方式完成。企業(yè)可以自動掃描源代碼及基礎設施中的漏洞，但在決定安全優(yōu)先級以及具體實施方式時還是少不了人類知識的加持。同樣的，我們在設計及代碼層級上建立安全標準時同樣無法完全依賴自動化技術。

歐盟推行的《通用數(shù)據(jù)保護條例》(GDPR)也開始明確要求在設計層面制定并實施安全標準。

另一方面，使用RBAC等編排工具/服務網(wǎng)格功能建立起的細粒度策略，則能夠在運營層面上實現(xiàn)一定程度的標準自動化。而且與應用程序源代碼內(nèi)的安全標準設計類似，我們也有必要將基于角色的訪問策略設計全面推廣，并將其視為一項高優(yōu)先級任務。

第五，容器與服務管理

在部署基于容器的大型應用程序時，以Kubernetes為代表的容器編排工具已經(jīng)成為不可或缺的元素。服務網(wǎng)格能夠與編排工具協(xié)同工作，并管理服務發(fā)現(xiàn)、訪問活動等常見行為，同時快速厘清用戶、基于容器的應用程序以及各外部服務之間的關系，幫助我們清晰明確地認識當前運營體系的總體情況。

而此類工具已經(jīng)成為DevSecOps中的關鍵元素，它們能夠充分容器與外部世界之間的高可擴展性隔離層(借此保證用戶或者潛在攻擊者只能訪問隱藏在代理之后的服務，卻無法觸及任何單一容器)，并借此實現(xiàn)身份驗證、授權(quán)及加密等功能。更重要的是，這些工具在設計之初就充分考慮到了自動化需求，因此更易于匹配現(xiàn)代開發(fā)及運營環(huán)境。

但與云服務供應商提供的安全工具相比，編排工具及服務網(wǎng)格要求我們對其中的安全功能進行深入研究，并在必要時主動配置并加以啟用。例如，Kubernetes中基于角色的訪問配置(RBAC)雖然已經(jīng)成為DevSecOps領域的一大重要元素，但默認情況下并未直接啟用。

小結(jié)

要實現(xiàn)DevSecOps，大家必須對現(xiàn)有IT資源及DevOps流程開展全面評估，而后建立起整體戰(zhàn)略以確保將高水平安全機制集成至流程之內(nèi)。除了前文提到的內(nèi)容之外，DevSecOps還包含眾多其他應被納入實施策略的重要元素，例如監(jiān)控、日志分析與警報等。但其中不少已經(jīng)成為軟件及互聯(lián)網(wǎng)安全領域的標準元素，因此本文不再另作贅述。

當安全性與CI/CD管道實現(xiàn)全面集成時，DevOps也將與DevSecOps彼此相融，共同成為“次世代軟件開發(fā)”的新范式、新標準。