零信任體系化能力建設(shè)（4）：應(yīng)用安全與開發(fā)部署

前言：應(yīng)用和工作負載是企業(yè)資產(chǎn)的重要組成部分，也是用戶訪問企業(yè)數(shù)據(jù)的主要手段和攻擊者關(guān)注的首要目標(biāo)，因此，強化對IT棧內(nèi)軟件部分的安全控制是企業(yè)推進零信任成熟度的必由之路。
通常，零信任網(wǎng)絡(luò)訪問（ZTNA）通過身份認證和訪問控制機制來保護業(yè)務(wù)應(yīng)用和資源，然而這些措施并不能為應(yīng)用提供更全面的保護，例如SQL（或代碼）注入、遠程指令執(zhí)行、容器權(quán)限逃逸等。本文從零信任安全能力的體系化建設(shè)入手，主要討論應(yīng)用和工作負載在訪問授權(quán)、威脅保護、開發(fā)部署和安全測試等方面的問題。
關(guān)鍵字：零信任；應(yīng)用安全；工作負載安全；開發(fā)部署；安全測試

一

零信任應(yīng)用安全

應(yīng)用和工作負載（簡稱應(yīng)用）是指運行在私有化、移動設(shè)備和云等環(huán)境中的系統(tǒng)、計算機程序和服務(wù)。在企業(yè)的業(yè)務(wù)環(huán)境中，數(shù)目龐大的應(yīng)用為各部門提供了復(fù)雜多樣的業(yè)務(wù)功能，它們依賴著不同來源的組件，其中隱藏著不同類型的安全漏洞，并在不同的訪問場景中扮演著不同的角色。

然而，基于邊界的安全模型假定了內(nèi)網(wǎng)的默認安全，也抑制了對應(yīng)用開發(fā)的安全性需求。教育機構(gòu)忽視了對應(yīng)用安全設(shè)計或編碼的教學(xué)培訓(xùn)，開發(fā)人員普遍缺乏生產(chǎn)安全產(chǎn)品的技能，安全措施經(jīng)常在應(yīng)用開發(fā)完成（甚至安全事件發(fā)生）后，以追加模式附著于應(yīng)用程序。在應(yīng)用生命周期的后期（運行或維護階段），運維人員甚至可能疏忽對安全漏洞的掃描和修復(fù)。

在應(yīng)用領(lǐng)域建設(shè)零信任安全能力，通常要面對比終端和網(wǎng)絡(luò)等領(lǐng)域更為復(fù)雜的局面，應(yīng)用的訪問方式（例如，通信機制、共享機制，以及認證方法等）、行為特征、編碼安全、開發(fā)部署、交付更新等問題均需進行梳理分析，并進行合理的改進優(yōu)化。

另外，在大多數(shù)時候，盡管應(yīng)用安全是從OSI參考架構(gòu)應(yīng)用層的視角去進行觀察和分析的，但安全能力的構(gòu)建實際上需要從更低的層次開始，對應(yīng)用層的保護需要借助或依賴網(wǎng)絡(luò)層和傳輸層的安全能力，不同層次安全能力的關(guān)聯(lián)、集成和協(xié)作是減少暴露面、提高可見性、推進零信任成熟度的關(guān)鍵。

二

應(yīng)用安全的關(guān)鍵能力

在零信任安全框架中，應(yīng)用安全能力既要確保應(yīng)用和工作負載間的安全訪問授權(quán)，阻止橫向移動和非法訪問，也要保障應(yīng)用層的協(xié)議和內(nèi)容安全，識別并阻斷惡意內(nèi)容和威脅，同時還要保證應(yīng)用的全生命周期安全（包括設(shè)計、開發(fā)、測試、部署和運維），以適應(yīng)不斷變化的威脅環(huán)境和安全需求。

1

訪問與授權(quán)

通過為應(yīng)用和工作負載建立統(tǒng)一數(shù)字身份，可以在“身份”領(lǐng)域建設(shè)應(yīng)用相關(guān)的訪問與授權(quán)能力。在向不同應(yīng)用集成訪問授權(quán)能力時，需要特別關(guān)注其工作流的特異性，并考慮如下問題：●如何在應(yīng)用層面實施和管理訪問授權(quán)，授權(quán)的粒度如何劃分？●應(yīng)用訪問授權(quán)會帶來什么樣的威脅？組織如何減輕對工作負載的威脅？●應(yīng)用程序如何被訪問？是否可通過互聯(lián)網(wǎng)訪問？●如何生成分析報告，以協(xié)助改善保護措施和安全策略？

零信任希望為用戶提供與位置無關(guān)的安全訪問。在應(yīng)用支柱的最佳成熟度級別，無論用戶身在各處（內(nèi)網(wǎng)、互聯(lián)網(wǎng)等），組織都應(yīng)該向用戶提供基于零信任的應(yīng)用訪問通道，減少訪問延遲，并提供一致的、良好的用戶體驗。

在向互聯(lián)網(wǎng)開放應(yīng)用訪問時，通常也需要利用傳輸層和網(wǎng)絡(luò)層的安全機制（例如，mTLS、IPSec等），實現(xiàn)在公共互聯(lián)網(wǎng)上的安全連接，確保數(shù)據(jù)在通信路徑的完整性和機密性。

2

威脅與保護

任何應(yīng)用程序都可能存在漏洞。鑒于應(yīng)用對企業(yè)的重要性，攻擊者也始終將應(yīng)用作為首要的攻擊目標(biāo)。作為零信任策略的一部分，持續(xù)監(jiān)控并保護應(yīng)用安全至關(guān)重要。

為防止?jié)撛诘穆┒幢还粽呃?，需要在?yīng)用層面實施多層次的保護機制。例如，通過WAF技術(shù)來檢測、識別和阻止對常見漏洞（例如，OWASP Top 10）的利用和Web攻擊，包括跨站腳本（XSS）、SQL注入、跨站請求偽造（CSRF）等。

另外，影子IT和API安全也是不容忽視的安全風(fēng)險，未經(jīng)批準的云應(yīng)用程序和服務(wù)，或API非法調(diào)用都可能導(dǎo)致數(shù)據(jù)泄露和安全風(fēng)險。CASB通過監(jiān)控和管理云應(yīng)用程序的使用情況，識別和控制未經(jīng)授權(quán)的應(yīng)用程序訪問，減少影子IT帶來的風(fēng)險，還可以通過提供API保護功能，監(jiān)控和管理云應(yīng)用程序的API訪問，確保API的安全性和合規(guī)性。

3

開發(fā)與部署

隨著組織構(gòu)建越來越多的云原生應(yīng)用程序，并采用大量開源組件來加速開發(fā)流程，如何將安全性更輕松地融入到開發(fā)和部署過程中，也是一個日益復(fù)雜的問題。

通常，開發(fā)團隊使用特定的DevOps工具和流程，形成了獨特的開發(fā)孤島。而且，開發(fā)人員的首要目標(biāo)與基本的安全優(yōu)先事項并不一致，他們更專注于快速交付業(yè)務(wù)部門所需的應(yīng)用功能，而管理或安全團隊則希望進一步降低業(yè)務(wù)風(fēng)險，并提供合規(guī)性支持，這些目標(biāo)分歧使應(yīng)用程序安全性進一步復(fù)雜化。

在軟件開發(fā)生命周期（SDLC）中引入安全考慮，通過安全左移，可以避免開發(fā)團隊在開發(fā)后期被迫進行安全修復(fù)所面臨的低效問題。

圖1 適用于各個SDLC階段的DevSecOps工具

在圖1中，Gartner概述了SDLC的七個階段，并給出了適用于每個階段的DevSecOps工具。軟件工程領(lǐng)導(dǎo)者應(yīng)與安全和風(fēng)險團隊以及基礎(chǔ)設(shè)施和運營方面的同行合作，在SDLC的每個階段集成工具。零信任應(yīng)用安全的重點是“確保應(yīng)用程序可用且安全，并且了解它們正在做什么”。開發(fā)團隊需要找到一種與DevOps有效合作的方法，以實現(xiàn)效率和安全的平衡，降低實現(xiàn)零信任目標(biāo)的難度。

4

安全與測試

盡管大多數(shù)組織并不具備安全編碼的培訓(xùn)能力，但仍然可以通過提供豐富的安全工具，幫助開發(fā)者發(fā)現(xiàn)并處理應(yīng)用中的安全缺陷。引入并充分利用這些安全測試工具，能夠逐漸緩解因開發(fā)者安全編碼經(jīng)驗不足，所帶來的應(yīng)用安全問題。

應(yīng)用程序安全測試涉及對漏洞和弱點的測試，常見方法包括靜/動態(tài)軟件測試、代碼審查、滲透測試、漏洞掃描、配置審計和安全評估等。

● 靜態(tài)應(yīng)用安全測試（SAST）：通過分析源代碼或應(yīng)用程序的二進制文件，檢測潛在的安全漏洞、軟件缺陷；●動態(tài)應(yīng)用安全測試（DAST）：通過模擬攻擊者的行為，對正在運行的應(yīng)用程序進行測試，以發(fā)現(xiàn)實時的漏洞和弱點；●代碼審查：對應(yīng)用程序代碼進行系統(tǒng)、詳細的審查和分析，以發(fā)現(xiàn)潛在安全問題，確保符合最佳實踐和規(guī)范；●滲透測試：模擬真實的攻擊行為，主動尋找應(yīng)用程序的弱點，測試其安全性；漏洞掃描：使用自動化工具掃描應(yīng)用程序，尋找已知的漏洞和常見的安全問題?！衽渲脤徲嫞簷z查應(yīng)用程序的配置文件和設(shè)置，確保其安全性和合規(guī)性；●安全評估：綜合考慮應(yīng)用程序的各個方面，包括架構(gòu)、設(shè)計、代碼、配置等，評估其整體安全性。

圖2 零信任應(yīng)用安全測試的主要方法

這些安全工具增強了開發(fā)人員的安全能力，但簡單部署這些工具并不能完全實現(xiàn)零信任目標(biāo)，開發(fā)人員需要將威脅模型應(yīng)用到他們的代碼中，并采取思維方式來考慮攻擊者可能訪問的內(nèi)容，以及他們會怎樣破壞應(yīng)用程序或周圍的供應(yīng)鏈，將應(yīng)用安全編織到零信任安全體系中。

三

應(yīng)用安全的最佳實踐

零信任是一種可適用于軟件供應(yīng)鏈的思維方式和方法，可以由外向內(nèi)或由內(nèi)向外應(yīng)用于軟件開發(fā)的流程中，使開發(fā)人員更快速地開發(fā)、交付更安全的應(yīng)用。

1

建立軟件物料清單

與零信任其他能力支柱的建設(shè)情況類似，應(yīng)用安全能力建設(shè)的第一步是發(fā)現(xiàn)組織環(huán)境中存在的軟件，并對其進行分類。盡管這是一個具有挑戰(zhàn)性的目標(biāo)，但可以通過一些流量分析或軟件成分分析（SCA）工具，識別并清點網(wǎng)絡(luò)中的應(yīng)用程序。

該清單應(yīng)盡可能覆蓋軟件供應(yīng)鏈中的所有組成，包括代碼中的依賴項、調(diào)用的服務(wù)、公開或訪問的API、工作負載以及用于開發(fā)、托管、集成和構(gòu)建應(yīng)用程序的工具。

軟件物料清單信息為在組織中實施零信任應(yīng)用安全策略提供了基礎(chǔ)。例如，通過分析CI/CD流水線和部署環(huán)境，為其設(shè)計并實施微隔離，或者了解每個軟件組件的版本，以確定應(yīng)用中是否存在已知的安全漏洞，并制定升級計劃，也可以基于容器清單，規(guī)劃不可變工作負載的替代方案。

2

改進開發(fā)安全流程

在大多數(shù)組織中，應(yīng)用開發(fā)和部署通常由許多不同的團隊負責(zé)，那么其安全和管理任務(wù)應(yīng)該由誰來承擔(dān)？

有一種觀點認為，應(yīng)用安全責(zé)任應(yīng)該由開發(fā)人員承擔(dān)。盡管大家都同意安全編碼是開發(fā)人員的責(zé)任，但引入安全相關(guān)工作可能會產(chǎn)生一些非預(yù)期的后果（例如，延遲交付）。另一種觀點是，安全團隊?wèi)?yīng)該通過尋找和消除可能的安全漏洞，來負責(zé)應(yīng)用的安全性。但是，由于開發(fā)周期的快速迭代，可能導(dǎo)致安全檢查的覆蓋范圍存在疏忽。

此外，在軟件開發(fā)生命周期中，分析、設(shè)計和構(gòu)建等每個流程都有特定的風(fēng)險要求，而不僅僅是安全編碼就一定能生成安全的應(yīng)用，特別是，合規(guī)性并沒有真正出現(xiàn)在SDLC的視野中，組織需要采用基于DevSecOps的流程，以端到端模式解決應(yīng)用開發(fā)的安全治理問題。

3

持續(xù)監(jiān)控維護更新

為了維護組織環(huán)境的應(yīng)用安全，需要持續(xù)跟蹤安全威脅的變化，保證應(yīng)用安全姿態(tài)的可觀察性，以便隨時優(yōu)化應(yīng)用程序，以減少攻擊面和防范風(fēng)險。通過定義安全性能指標(biāo)，配置全面的日志記錄，引入異常監(jiān)測和性能監(jiān)控，持續(xù)監(jiān)控應(yīng)用的運行狀態(tài)，可以及時發(fā)現(xiàn)問題、優(yōu)化性能，并提前識別潛在的安全風(fēng)險。

過去，大多數(shù)組織都使用CVSS評分對漏洞進行優(yōu)先級排序。從邏輯上講，關(guān)注漏洞的嚴重性似乎是正確的，但更重要的問題是該漏洞是否可被利用。EPSS模型根據(jù)漏洞的特性和已知的攻擊模式，對漏洞的潛在可利用性進行評估，可以提供對漏洞利用可能性的估計，從而幫助安全團隊確定哪些漏洞可能是攻擊者的首要目標(biāo)。

結(jié)合這兩個評估系統(tǒng)，安全團隊可以制定更全面和有效的漏洞修復(fù)策略，優(yōu)先處理那些同時具有高CVSS評分和高EPSS評分的漏洞，以最大程度地減少系統(tǒng)面臨的風(fēng)險。

四

結(jié)語

數(shù)字化轉(zhuǎn)型的加速迫使組織重新評估其安全策略和基礎(chǔ)設(shè)施，推動了零信任應(yīng)用程序安全性和合規(guī)性的需求增長。在致力于零信任建設(shè)的組織中，應(yīng)用程序安全經(jīng)理有很多方法來實施相關(guān)行動，為變革創(chuàng)造動力，但最終仍需要與其他支柱中構(gòu)建的解決方案相結(jié)合，或通過與其他團隊協(xié)作構(gòu)建相關(guān)能力（例如，統(tǒng)一身份庫、持續(xù)認證和授權(quán)、分段資源池以及數(shù)據(jù)分類和保護），以支持應(yīng)用支柱中的零信任目標(biāo)和組織業(yè)務(wù)。

審核編輯 黃宇