受管 CNAPP：將雲端原生安全營運外包

什麼是受管 CNAPP？

受管 CNAPP 是一種服務模式，由供應商代表您執行雲端原生應用程式保護平台（CNAPP）及其安全營運。平台仍然屬於您，責任也一樣。改變的是由誰負責值守。

對該監控的要求現已寫入聯邦政策。2024 年 12 月，CISA 的 Binding Operational Directive 25-01 要求聯邦民間機構找出並修正雲端組態錯誤，並在其雲端租戶中執行持續監控，因為錯誤設定的控制措施讓攻擊者取得資料外洩的途徑。關鍵字是「持續」。要在您執行的每個帳戶中維持這種程度的涵蓋範圍，是少數精簡團隊能夠全天候配置人力完成的工作，而受管模型的存在正是為了彌補這個缺口。

受管 CNAPP 與網路安全的關聯

雲端原生安全涵蓋組態、身分、工作負載與 Kubernetes，而每一層都會全天候產生發現。 

一個 CNAPP 會將這些層面整合到單一平台中。受管模式則在其背後配置一支有人員值守的團隊，因此在夜間與週末也能維持涵蓋範圍；此時，暴露的儲存貯體或權限過大的角色，對攻擊者而言與正午時分一樣容易接觸。供應商負責營運，而在 共同責任模型之下，您的組織仍須對其雲端安全態勢與法規遵循負責。

受管 CNAPP 服務的核心組成

受管 CNAPP 服務有兩個層面：產生發現的平台，以及對這些發現採取行動的人員與流程。

底層 CNAPP 所涵蓋的內容

此平台整合四項能力，每一項都是受管供應商操作的一個層面，讓您的團隊能從建置到執行階段，在單一位置檢視雲端風險：

• 雲端安全態勢管理（CSPM） 可找出雲端基礎架構中的錯誤組態與法規遵循違規，從開放的儲存貯體到過於寬鬆的防火牆規則皆包含在內。
• 雲端工作負載保護（CWP） 可在公有、私有與混合環境中，於執行階段保護容器、虛擬機器、無伺服器函式與伺服器。
• 雲端基礎架構權限管理（CIEM） 會分析人類與非人類身分的權限，標示過高權限並強制執行最小權限原則。
• Kubernetes 安全態勢管理（KSPM） 會對 Kubernetes 叢集執行 錯誤組態檢查，並驗證法規遵循一致性。

它們共同回答有關您雲端的四個具體問題：哪些組態與法規遵循控制已發生偏移（CSPM）、哪些執行中的工作負載正遭受攻擊（CWP）、哪些人類與非人類身分擁有超出所需的存取權（CIEM），以及哪些 Kubernetes 叢集存在錯誤組態（KSPM）。

平台會持續回報這些發現，但不會對其進行分級處理、依可利用性排序，或將其指派給負責人。這正是受管服務所承擔的工作。

受管服務新增的內容

在授權平台之上，供應商還提供一個有人員配置的營運層，負責其日常運作：

供應商的人員配置與明確定義的涵蓋時段，正是此服務為原本可由您自行運作的平台所增加的價值。至於自行運作是否是正確選擇，則是下一個問題。

受管 CNAPP 的運作方式

受管 CNAPP 服務會以六個階段形成持續循環。供應商負責營運步驟。當某項發現轉變為您必須採取行動的工作時，您的團隊便會進入此循環，因此您能清楚知道責任在何處交還給您。

1. 上線與整合。 供應商會連接您在 AWS、Azure、GCP 及任何其他所使用供應商上的雲端帳戶。在開始調校之前，需先完成所有帳戶（包括開發人員帳戶）的完整部署，以建立基準。
2. 無代理掃描與執行階段涵蓋。 供應商會啟用兩層可視性。 無代理掃描 會查詢雲端供應商 API，以評估組態、權限與弱點，而無需在工作負載上安裝軟體。以代理程式或感測器為基礎的涵蓋則可為 Kubernetes 叢集，以及容器或虛擬機器 (VM) 中的工作負載，提供即時的執行階段防護。
3. 持續監控。 掃描會持續執行，因此新的帳戶、工作負載與組態變更會在出現時納入涵蓋範圍。安全態勢與弱點狀況可在各檢查點之間維持最新。
4. 警示分類與優先排序。 供應商會過濾誤判，並依可利用性與曝險程度對已確認的發現結果進行排序，且排序中會反映業務影響。
5. 修復與事件回應交接。 供應商會將已排定優先順序的發現結果，連同採取行動所需的情境資訊，轉交給負責團隊。供應商負責發現、分類與轉派。您的團隊負責執行修復。
6. 報告。 供應商會依既定頻率提供報告，並將安全指標連結至業務成果。

這個循環永不停止。唯一的問題是應由誰來執行：您的內部團隊，還是供應商。 

何時應將雲端原生安全營運外包

在內部執行 CNAPP 營運與交由供應商處理之間的選擇，取決於您團隊的人力配置、專業能力、涵蓋需求與控制需求。

沿著外包光譜可分為三種服務模式：

• 自行管理的 CNAPP 表示您授權使用該平台，並在內部營運。您的分析師負責監控、調校發現結果、分類警示，並推動修復。
• 共同管理的 CNAPP 表示供應商提供平台與營運專業能力，處理上線導入、調校、警示優先排序與升級支援。您仍保有調查與修復決策的主要責任。
• 完全代管的 CNAPP 表示供應商承擔監控、分類、調查與修復協調的營運責任。您仍保有治理權限，以及對已轉派發現結果的修復執行責任。

您在此光譜中的定位，決定了您付費購買的是什麼，以及您仍需負責什麼。下一個問題是，特定供應商是否能在您的整體雲端環境中提供這些能力。

評估代管式 CNAPP 供應商時應注意什麼

受管 CNAPP 供應商 的評估依據有兩個類別：規範合作關係的服務層級承諾，以及決定其是否能涵蓋您雲端資產的技術整合。

SLA 考量

可衡量的服務層級協議 (SLA) 會定義具體且有時限的承諾。模糊的 SLA 會承諾「快速回應」，卻不說明快速的定義。MITRE 的 雲端 SLA 分析 發現，效能水準的定義方式以及供應商與使用者之間的風險分擔方式存在相當大的差異。請閱讀定義，而不是形容詞。

評估 SLA 時，請聚焦於對應營運風險的承諾：

• 已確認發現項目的回應時間，以及值班升級模型
• 涵蓋時段與警示分類處理周轉時間
• 誤判處理率與修復路由速度
• 報告頻率

要求具契約約束力的 SLA。確認供應商是否透明地報告 SLA 績效，以及未達 SLA 時會發生什麼情況。

多雲整合需求

您的供應商必須能連接您營運的每個雲端環境。評估無代理程式上線流程：供應商能多快連接到您的 AWS、Azure 和 GCP 帳戶並開始掃描。確認涵蓋範圍是否延伸至您使用的任何其他雲端供應商。 SentinelOne's Singularity™ Cloud，例如，可從單一主控台涵蓋 AWS、Azure、GCP、Oracle Cloud Infrastructure (OCI) 和 Alibaba Cloud。

評估容器與 Kubernetes 涵蓋範圍：供應商底層的 CNAPP 是否涵蓋您的 Kubernetes 叢集、容器登錄庫與無伺服器函數？確認有哪些資料會離開您的環境、儲存在何處，以及供應商的架構是否符合您的法規要求。

CIEM 應涵蓋身分與存取管理 (IAM) 政策中錯誤設定的評估與修復。

受管 CNAPP 的挑戰與限制

將雲端原生安全營運外包會帶來結構性限制，即使合作執行良好，這些限制仍然存在。

1. 直接可視性降低。 操作您 CNAPP 的供應商位於您的團隊與原始發現結果之間。Carnegie Mellon 的 Software Engineering Institute (SEI) 記錄了這項風險 在雲端外包中的情況：組織會失去對其移交資產與作業的可視性與控制權，而要恢復這些能力，則需要監控與分析，而這些原本是內部部署網路記錄所提供的。
2. 責任邊界模糊。 這裡涉及 共同責任模型：受管供應商在您的責任層內運作，而您的組織仍需對雲端供應商與監管機關負責。
3. 供應商依賴與鎖定。非標準資料格式、專有 API，以及對供應商特定工具的依賴，使得切換供應商的成本與工作量高於最初預期。
4. 供應商作為供應鏈風險。授予第三方對您雲端環境的營運存取權，本身就是需要管理的風險。英國的 NCSC 指出，不受控制且未受觀察的第三方存取是一種反模式：將管理或營運功能外包後，您就必須依賴另一個組織來維持系統安全。請限制該存取權。定義範圍邊界、監控供應商活動，並持續審查其人員、流程與技術。
5. 從警示到行動交接的延遲。 每個需要您團隊採取行動的發現項目，都會經過供應商的分類處理與路由流程。這種交接可能會延遲修復。
6. 快速變動資產中的涵蓋落差。新帳戶、新工作負載或新服務會在上線週期之間出現，而供應商的涵蓋範圍反映的是上次整合檢查點時環境的設定狀態。

上述每一項都是已知的失效模式。已知的失效模式是可以透過設計加以處理的。以下做法可在它們造成任何代價之前先行補強。

受管 CNAPP 最佳實務

能夠長期維持成效的合作關係都有一些共同的營運習慣。每一項都能補上原本會使外包安全工作停滯的失效模式。

在供應商路由任何單一發現項目之前，先以書面定義共同責任邊界。若未依發現項目類別指派結案責任，結果就會懸而未決，因為雙方都以為對方會處理。同樣的明確性也能保護您自身的責任歸屬：供應商負責營運，而您的組織仍擁有其雲端安全態勢、法規遵循與修復執行的責任。

將供應商接入您已在執行的工作流程中。將每種升級類型對應到您現有 IR runbooks 中的內部負責人，讓供應商的發現項目能以結構化回應工作的形式進入您的流程。 

同時保留您自己對 CNAPP 主控台以及供應商報告輸出的存取權，這樣您就能根據供應商自己的數據獨立驗證其績效。其餘合作內容也應依據您按固定頻率檢查的數據來治理：

• 追蹤您簽訂的 SLA，並依照既定排程進行檢視。沒有人衡量的 SLA 不具任何營運價值。
• 將報告與業務成果連結，讓每次檢視都能把安全性指標對應到其所保護的工作。
• 針對您的實際環境執行涵蓋範圍稽核，包括開發人員帳戶、預備環境，以及新佈建的雲端帳戶。

在涵蓋範圍之前先看價格，是一種代價高昂的捷徑：成本較低但只監看您部分環境的供應商，會讓其餘部分處於未受監控狀態。

CNAPP Buyer’s Guide

Learn everything you need to know about finding the right Cloud-Native Application Protection Platform for your organization.

Read Guide

使用 SentinelOne 強化 Managed CNAPP

Singularity Cloud Security 是 SentinelOne 的 CNAPP。它從建置階段一路運作到執行階段，透過無代理程式姿態管理與即時工作負載防護，涵蓋雲端帳戶、容器、Kubernetes、AI 服務與無伺服器環境。一個主控台即可涵蓋 AWS、Azure、GCP、OCI 與 Alibaba Cloud。 

無代理程式層 Singularity Cloud Native Security，會透過 Verified Exploit Paths 確認哪些發現確實可被利用，讓供應商能將高價值發現導向正確的負責人，並減少花在雜訊上的時間。在執行階段，自動回應動作包括終止程序、網路隔離、檔案隔離與 Pod 中斷連線，可在分析師介入前控制事件。Singularity Platform 將端點、雲端與身分識別遙測整合到單一代理程式、主控台與資料湖中。在 2024 MITRE ATT&CK® Evaluations 中，它以 100% 識別率記錄到少 88% 的警示。

透過 Purple AI™，自然語言威脅搜尋與代理式調查可減少分析師蒐集證據所花費的時間。IDC 於 2025 年 4 月的快照指出，其可將威脅識別速度提升 63%，並將修復速度提升 55%。供應商可以代表您執行所有這些工作。精簡的內部團隊也可以直接操作它。

預約 SentinelOne 示範，了解 Singularity Cloud 如何減輕您團隊的負擔。

Cloud Security Demo

Discover how AI-powered cloud security can protect your organization in a one-on-one demo with a SentinelOne product expert.

Get a Demo

重點整理

Managed CNAPP 會將執行雲端原生應用程式防護平台的營運負擔轉移給供應商，由其代表您配置監控、分流與修復路由的人力。是否決定外包，取決於您團隊的人力配置、您的涵蓋需求，以及您雲端環境的複雜度。 

成功的合作建立在明確定義的責任邊界、可衡量的 SLA、整合至您的事件回應工作流程，以及持續的涵蓋範圍驗證之上。這四點做好後，外包就不再等同於失去控制。您設定邊界、掌握治理，並且不必再成為凌晨 3 點分流警示的人。