一、前言
云計算、大數據和人工智能的來臨，上云已經成為組織數字化轉型的必由之路。云原生作為云計算的下一個階段，相關的開發和部署模式已經成為業界趨勢，技術、產品、標準和解決方案的生態系統也在同步擴張之中，決策者面臨著跟進這些復雜設計的挑戰。
云原生技術應用產生了新的云安全需求，CISO 要在競爭激烈的云原生市場中確保業務安全。傳統的防火墻、反病毒、服務器監控、終端檢測響應和SIEM等安全產品，與云原生的適配性較好，容易部署上云。但工作負載安全、威脅檢測、用戶行為監控、合規與風險管理等安全產品，無法適應云原生技術的新安全需求，需要進行專門的重新設計。
過去的幾年，誕生了云工作負載保護平臺CWPP（Cloud Workload Protection Platform）、云安全態勢管理CSPM（Cloud Security Posture Management）等云安全產品，對云原生安全的保護發揮了重要作用。但是，隨著新應用場景的出現、技術的演化和市場的變化趨勢，云原生應用保護平臺（Cloud-Native Application Protection Platform, CNAPP）的概念誕生，漸有統一CWPP和CSPM之勢。本文將對CNAPP的發展演進脈絡進行分析。
二、傳統主機保護平臺
01 終端保護平臺
云原生應用程序保護平臺最初起源于終端保護平臺（Endpoint Protection Platform，EPP）。雖然一些企業現在仍在使用EPP產品作為保護服務器工作負載的安全產品，但是EPP是面向物理終端設備（臺式機、筆記本電腦和平板電腦等）的解決方案，不適合企業混合云場景下的工作負載保護的要求。
在這種場景下，基礎架構是由本地服務器、虛擬服務器以及公有云環境共同組成，主要的保護目標是服務器的工作負載。EPP產品的繼續使用會使企業的數據和應用程序處在巨大的安全風險之中。傳統的以數據中心、網絡和終端為主要保護對象的安全理念和產品，需要向混合云場景進行演進。
02 混合云場景下的云工作負載保護平臺
混合云的部署架構逐漸被市場接受。為了滿足混合云場景下的工作負載保護，云工作負載保護平臺（Cloud Workload Protection Platform, CWPP）隨之產生。CWPP最初（2016年）基于主機安全的解決方案進行定義，區別于EPP的PC維度，CWPP主要解決的問題在于數據中心維度。CWPP強調了混合數據中心架構需要統一的管理、Linux系統的重點支持、殺毒軟件的無效、定價靈活性以及跟云平臺的對接和API與DevSecOps的結合等等。
從技術角度來看，最核心的是跟云平臺原生的對接，利用AWS或者Azure提供的接口來進行相關安全措施的處理。比如說通過VPC接口可以做到相關業務的微隔離，也可以通過網絡流量日志來進行流量的安全分析。
2017年，CWPP增加了外部場景的云工作負載安全服務（WAF、Firewall和IPS等），進一步增強云工作負載的保護。并且，開始采用控制面的安全措施（IAM配置、網絡配置以及管理員訪問等）。
此外，容器的出現，使得用戶無法對線上系統進行處理，安全措施需要前移到開發環節，并且運行時的應用控制和容器的鎖定需要作為新的防御手段，云工作負載保護架構隨之發生了變化。新架構要求對SDL流程的支持，與自動化CI/CD工具的結合，要求API可以靈活調用，將安全檢查前移。
03 混合多云場景下的云工作負載保護平臺
2018年，大部分組織開始在使用至少兩個廠商的云計算服務。混合多云的部署架構成為市場的主流。為了滿足混合多云場景下云工作負載保護，CWPP需要提供統一的安全策略管理，以減少企業的知識鴻溝。
同時，CWPP的管理需要自動化，從而更好地與DevSecOps相結合。例如，在自動化生成工作負載時，自動化安裝和配置相關的軟件或安全策略。
此外，CWPP開始注重機器學習技術對產品能力金字塔各個層面的加強作用。例如，對于微隔離層面，機器學習可以先學習和觀察正常的情況，然后建立白名單，隨著時間的推移不斷更新和修正策略以達到不用人工介入就可設置安全策略的狀態。
然而，CWPP并不能解決Serverless計算方式所帶來的安全問題，勢必需要對工作負載的定義進行重新和全面審視。因而，Gartner在2019年對工作負載的外延和內涵進行細粒度解釋，根據抽象度的不同分為物理機、虛擬機、容器和Serverless。
這幾種工作負載從虛擬化水平到單位的計量再到生命周期都有很大的區別。能力金字塔因而發生了重大變化。從原來的11個能力刪減到8個能力，并且將最底層的“運維習慣”與“加固、配置與漏洞管理”進行了整合。刪掉了“欺騙防御”能力，因為欺騙/蜜罐系統是單獨產品提供。同時數據的靜態加密大部分情況下都有云廠商提供，比如AWS的EBS加密和Azure的磁盤加密，因此“靜態加密IaaS數據”這個能力也從能力金字塔中刪掉了。但是加強了對威脅檢測和響應的要求，相當于要學習EDR的能力。
圖1：工作負載抽象
2020年，CWPP能力金字塔進一步精簡，文件加密和防病毒從其中移除。目前的能力，從最核心的開始，按照重要性逐漸遞減的排序，包括八層：加固、配置和漏洞管理，基于身份的隔離和網絡可視化，系統完整性保證，應用控制/白名單，預防漏洞利用和內存管理，服務器工作負載行為監測、威脅檢測和響應，主機防入侵和漏洞屏蔽，掃描惡意軟件。
圖2：基于風險的工作負載保護控制層次結構
三、云原生應用保護平臺
01 云原生應用保護平臺的產生背景
首先，從安全市場角度來看，云原生技術持續深入發展和廣泛普及勢必帶來新的網絡安全發展機遇，產生龐大的網絡安全需求，并推動云安全業務向縱深發展。
其次，從安全生態角度來看，安全產品的融合發展成為必然選擇。CWPP在數據面對云工作負載進行保護，CSPM在控制面對云工作負載進行保護。
值得注意的是，當前大多數的云安全事件都是配置錯誤和管控失當引起的，凸顯正確配置和合規的重要性，控制面的安全變得越加重要。數據面和控制面的云安全產品通過相互融合組成統一的解決方案，能夠更好地保護多云和多租戶，云原生應用保護平臺（CNAPP）由此產生。
最后，從云安全實際需求角度來看，混合多云仍將是組織和機構未來一段時期的基礎架構。
但是，工作負載的粒度、生命周期以及創建方式發生了顯著變化，云安全保護需求勢必也會發生變化。
首先，組織正在越來越多地采用容器和Serverless等技術進行云原生應用開發，工作負載的粒度越來越來越細，云原生安全保護需要適應工作負載粒度的變化。
其次，容器和Serverless等形式的云原生開發的流行，工作負載的生命周期越來越短，部署在這些工作負載上的惡意軟件也呈現出快速變化的特點。傳統的基于簽名文件加載或反惡意軟件掃描的方式無法及時響應，基于行為建模的方案也因無法收集足夠案例變得失效。云原生安全保護需要適應工作負載的生命周期越來越短的變化。
最后，工作負載越來越通過鏡像構建和替換，正在向不變的基礎設施轉變。云原生安全保護同樣需要適應這種變化。
02 云原生應用程序保護平臺的主要特點
總的來說，CNAPP將會吸收CWPP和CSPM的能力，不僅需要把不同的安全解決方案集成在一起，跨越不同技術邊界實施一致的安全策略，提供統一的云原生保護，還需要采用面向安全的架構設計（例如，零信任），識別動態工作負載中的屬性和元數據，自動化地保護開發、發布、部署和運營等整個生命周期。
首先，CNAPP無疑仍將聚焦動態混合、異構多云架構場景下的工作負載保護，重點是跨不同技術邊界實施一致的安全策略。
其次，CNAPP需要具備對所有粒度的工作負載進行保護的能力。云原生應用需要虛擬機、容器和無服務器PaaS組合起來提供服務，單一的工作負載保護無法保證應用的整體安全。并且，隨著工作負載的粒度和動態變化，CNAPP策略和產品也許必須動態適應、彈性伸縮。
第三，CNAPP需要對開發、發布、部署和運營等整個生命周期進行保護。現在的CWPP主要關注工作負載運營階段的保護，缺乏對其他階段的保護。CNAPP需要注重基于基礎設施的不變性進行保護。在開發階段，使用安全測試來識別合規和配置的相關問題，為持續改進提供快速、可操作的反饋流程。在發布階段，持續地對工作負載鏡像（例如容器鏡像）進行自動掃描和更新，避免遭受漏洞、惡意軟件、危險代碼以及其它不當行為的侵害，確保所依賴的開源軟件和第三方應用等軟件供應鏈的安全。在部署時，對工作負載鏡像的屬性進行的驗證（例如，簽名、安全策略等）。
第四，CNAPP需要適應云原生開發的快速迭代，基于CI/CD 實現自動化。云原生追求的本質目標是效率，CI/CD作為效率提升的重要手段，是云原生的關鍵特性。云原生時代，不滿足CI/CD自動化的安全產品，將摧毀云原生的價值，也就不能算作云原生安全保護。
第五，CNAPP需要重點加強配置保護和合規性檢查能力。云計算基礎設施錯誤配置帶來的安全風險要比攻破工作負載帶來的安全風險更大。CSPM能夠對云計算技術設施的配置和合規性進行持續評估和改進，CNAPP需要充分吸收CSPM的這種能力。
第六，CNAPP需具備對云原生應用程序進行威脅檢測和響應的能力。CWPP主要依賴于預防性控制，而CNAPP需要采用CARTA戰略框架和自適應安全架構，對云原生應用程序以及相關工作負載的行為進行監控。