[[407331]]

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

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

DevSecOps是什么?

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

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

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

DevSecOps實踐與工具

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

第一，漏洞掃描

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

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

第二，運行時保護

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

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

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

第三，云服務(wù)供應(yīng)商

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

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

第四，標(biāo)準(zhǔn)與政策

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

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

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

第五，容器與服務(wù)管理

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

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

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

小結(jié)

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

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