3 min read已更新 Oct 8, 2026

託管式 CNAPP: 將雲原生安全營運委外

Q: 什麼是代管式 CNAPP?

代管式 CNAPP 是由服務供應商代您營運 雲端原生應用程式防護平台 的服務模式. 供應商負責跨雲端環境持續管理安全態勢、修正錯誤設定、分流警報, 並回應執行階段威脅. 您仍保有事件升級決策的治理權, 並對修復工作的執行負責. 這種模式將營運 CNAPP 的工作交給外部雲端安全專家, 包括配置分析人員及持續調整偵測結果.

託管式 CNAPP 將雲原生應用程式保護平台的營運交由服務供應商負責. 了解服務模式、何時該委外，以及如何選擇供應商.

作者 SentinelOne

Reviewer: Joe Coletta

重點摘要

代管式 CNAPP 是由供應商營運您的 CNAPP 及相關安全作業的服務.
供應商負責監控、警報分流及指派修復工作, 您則保有治理權並承擔責任.
服務模式涵蓋自行管理、共同管理及完全代管.
若團隊人力精簡、需要全天候涵蓋, 或營運多雲環境, 可考慮外包.
依據 SLA、多雲與 Kubernetes 涵蓋範圍, 以及資料處理方式評估供應商.

什麼是託管式 CNAPP?

託管式 CNAPP 是一種服務模式，由服務供應商代您營運雲原生應用程式保護平台 (CNAPP) 及其安全作業. 平台仍歸您所有. 責任也是如此. 改變的是由誰負責監控.

這項監控的標準如今已寫入美國聯邦政策. 2024 年 12 月, CISA 的具約束力作業指令 25-01 要求聯邦文職機構找出並修正雲端設定錯誤, 並持續監控其雲端租戶, 因為設定錯誤的控制措施曾讓攻擊者有機可乘並竊取資料. 關鍵在於「持續」. 要在您管理的每個帳戶維持這種程度的監控, 少有精簡團隊能全天候投入足夠人力, 而代管模式正是為了填補這道缺口. 供應商將這種模式稱為代管式 CNAPP 服務. 它屬於範圍更廣的代管式雲端安全服務, 並以您的 CNAPP 為核心.

託管式 CNAPP 與網路安全的關係

雲原生安全涵蓋組態、身分、工作負載和 Kubernetes, 而每一層都全天候產生安全發現.

一套 CNAPP 將這些層面整合至單一平台. 託管模式則由專責團隊負責營運, 讓夜間和週末的防護不中斷, 因為暴露的儲存貯體或權限過高的角色, 對攻擊者來說和正午一樣容易觸及. 服務供應商負責營運, 而根據共同責任模型, 貴組織仍須對自身的雲端安全態勢和法規遵循負責.

託管式 CNAPP vs. MDR vs. MSSP

託管式 CNAPP、MDR 和 MSSP 服務雖有重疊, 但各自涵蓋不同範疇.

	託管式 CNAPP	MDR	MSSP
主要重點	雲端安全態勢、工作負載、身分和 Kubernetes	主動式威脅偵測與應變	安全工具監控與警示
服務供應商負責的作業	日常營運您的 CNAPP	威脅獵捕、調查與應變	監控, 通常涵蓋多項工具
您獲得的成果	依優先順序排列的組態錯誤、權限檢查結果和執行階段警示	已調查的事件和遏止措施	警示、工單和定期報告
最適合	擁有 CNAPP 卻無法配置人力營運的團隊	需要 24/7 威脅獵捕與應變的團隊	需要委外監控與報告的團隊

許多雲端團隊會同時採用託管式 CNAPP 與 MDR. 託管式 CNAPP 在攻擊發生前降低暴露風險, MDR 則在攻擊進行時做出應變.

託管式 CNAPP 服務的核心組成

託管式 CNAPP 服務分為兩層: 產生安全發現的平台, 以及根據發現採取行動的人員與流程.

底層 CNAPP 的涵蓋範圍

平台整合四項能力, 每項都由託管服務供應商負責營運, 讓您的團隊能在同一處掌握從建置到執行階段的雲端風險:

雲端安全態勢管理 (CSPM) 找出雲端基礎架構中的組態錯誤和合規違規情形, 從開放的儲存貯體到權限過於寬鬆的防火牆規則.
雲端工作負載防護 (CWP) 保護公有雲、私有雲和混合環境中執行的容器、虛擬機器、無伺服器函式與伺服器.
雲端基礎架構權限管理 (CIEM) 分析人類與非人類身分的權限, 標示過高權限並落實最小權限原則.
Kubernetes 安全態勢管理 (KSPM) 執行組態錯誤檢查, 針對 Kubernetes 叢集進行檢查並驗證其是否符合法規遵循要求.

這些能力共同回答關於您雲端環境的四個具體問題: 哪些組態和合規控制已偏離基準 (CSPM), 哪些執行中的工作負載正遭受攻擊 (CWP), 哪些人類與非人類身分擁有超出所需的存取權限 (CIEM), 以及哪些 Kubernetes 叢集的設定有誤 (KSPM).

平台會持續回報這些發現, 但不會進行分類處理, 依可利用性排序, 或轉交負責人. 這些工作由託管服務承擔.

託管服務提供的額外支援

除了授權使用的平台, 服務供應商還提供由專人負責的營運層, 執行日常作業:

營運層	服務供應商的工作
持續態勢管理	隨著已連接帳戶中的基礎架構設定逐漸偏離基準, 持續追蹤設定與合規狀態.
設定錯誤修復	找出問題並排定優先順序, 轉交負責團隊, 並追蹤至結案.
弱點與權限管理	對作業系統與工作負載進行無代理程式掃描, 並透過 CIEM 分析權限過高的身分.
執行階段威脅應變	透過代理程式或感測器提供防護, 監控工作負載並在攻擊執行期間加以阻止.
分析師值守	對警示進行分類處理, 過濾誤報, 升級處理已確認的發現, 並依固定週期提供報告.

服務供應商提供的人員配置和明確的服務時段, 是這項服務在您原本可自行操作的平台之外提供的支援. 下一個問題是, 自行操作是否合適.

託管式 CNAPP 的運作方式

託管式 CNAPP 服務透過六個階段持續循環運作. 服務供應商負責營運步驟. 當發現轉化為需要您採取行動的工作時, 您的團隊便會加入流程, 因此能清楚知道責任何時交回團隊.

導入與整合. 服務供應商會連接您在 AWS, Azure, GCP 及其他雲端供應商的帳戶. 在開始調整設定前, 先完成所有帳戶的部署, 包括開發人員帳戶, 以建立基準.
無代理程式掃描與執行階段防護. 服務供應商會啟用兩層可視性. 無代理程式掃描透過查詢雲端供應商的 API 評估設定, 權限和弱點, 無須在工作負載上安裝軟體. 代理程式或感測器防護則為 Kubernetes 叢集及容器或虛擬機器 (VMs) 中的工作負載, 提供即時執行階段防護.
持續監控. 掃描持續進行, 讓新帳戶, 工作負載及設定變更一出現就納入涵蓋範圍. 在各次檢查之間, 態勢與弱點資訊也能維持最新狀態.
警示分類與優先排序. 服務供應商會過濾誤報, 並根據可利用性和暴露程度, 同時考量業務影響, 為已確認的發現排定優先順序.
修復與事件應變交接. 服務供應商會將排定優先順序的發現, 連同採取行動所需的背景資訊轉交負責團隊. 服務供應商負責發現, 分類處理及轉交. 您的團隊負責執行修復.
報告. 服務供應商會依既定週期提供報告, 將安全指標與業務成果連結.

這個循環永不停止. 唯一的問題是該由誰來執行: 您自己的團隊, 還是服務供應商.

託管式 CNAPP 的優勢

由服務供應商營運的 CNAPP, 將改變您團隊每週的工作安排.

分析師在夜間和週末值守, 讓高風險發現在 SLA 規定時間內完成分類處理.
完成無代理程式導入後數小時內, 即可掌握安全態勢, 遠快於任何招募流程.
服務供應商會過濾誤報, 並依可利用性為發現排序, 讓您收到的待處理項目已有優先順序.
無須為每個專業領域分別招募人才, 即可取得 Kubernetes, 容器及 CIEM 的專業支援.

何時該委外雲端原生安全營運

要由內部團隊執行 CNAPP 營運, 還是交給服務供應商, 取決於團隊的人力配置, 專業能力, 服務涵蓋需求及控制需求.

條件	適合委外	適合內部執行
雲端安全人力配置	團隊精簡, 專職雲端安全人員有限	成熟的 SOC, 配有專職雲端安全工程師
服務涵蓋時段	需要全天候服務, 目前團隊僅在上班時間提供服務	已配置跨時區接力或輪班人力
實現價值所需時間	需要快速建立營運涵蓋能力	有時間在內部建立並調校
多雲環境複雜度	使用多家雲端供應商, 帳戶分散於各業務單位	單一雲端或受到嚴格控管的雙雲環境
雲端原生專業能力	團隊擅長地端環境, 但對 Kubernetes, 容器或 IAM 的了解有限	對 CSPM, CWPP 和 CIEM 營運具備深厚的既有專業能力
控制權要求	願意與服務供應商界定共同責任的分界	嚴格的資料落地要求, 對第三方存取的法規限制, 或禁止將安全營運外包的政策
工具成熟度	CNAPP 最近才採購或尚未投入實際營運	CNAPP 已全面部署並完成調校, 團隊也能有效運用

依外包程度, 服務模式分為三種:

自行管理的 CNAPP 是指您取得平台授權並由內部團隊營運. 您的分析師負責監控值勤, 調校偵測結果, 分類處理警示並推動修復.
共同管理的 CNAPP 是指服務供應商提供平台與營運專業能力, 負責導入, 調校, 警示優先順序判定及升級處理支援. 調查與修復決策仍主要由您負責.
完全代管的 CNAPP 是指服務供應商承擔監控, 分類處理, 調查及修復協調的營運責任. 您仍保有治理決策權, 並負責執行轉交給您的偵測結果之修復作業.

您選擇的外包程度, 決定了付費購買哪些服務, 以及哪些責任仍由您承擔. 接下來的問題是, 特定服務供應商能否在您的整體雲端環境中提供這些服務.

評估代管 CNAPP 服務供應商的重點

代管型 CNAPP 服務供應商的評估分為兩類: 規範合作關係的服務層級承諾, 以及決定其能否涵蓋您整體雲端環境的技術整合能力.

SLA 考量事項

可衡量的服務層級協議 (SLA) 會訂明具體且有時限的承諾. 模糊的協議只承諾「快速回應」, 卻未說明多快才算快速. MITRE 的雲端 SLA 分析發現, 效能水準的定義方式, 以及服務供應商與客戶之間的風險分擔方式, 存在顯著差異. 請詳讀定義, 別只看形容詞.

評估 SLA 時, 請聚焦於與營運風險直接相關的承諾:

已確認偵測結果的回應時間與待命升級處理模式
服務涵蓋時段與警示分類處理所需時間
誤報處理率與修復任務轉派速度
報告頻率

要求具合約約束力的 SLA. 確認服務供應商是否透明揭露 SLA 達成情況, 以及未達標時如何處理.

多雲整合要求

服務供應商必須連接您使用的每個雲端環境. 評估無代理程式的導入作業: 服務供應商能以多快的速度連接您的 AWS, Azure 和 GCP 帳戶並開始掃描. 確認服務範圍是否涵蓋您使用的其他雲端供應商. SentinelOne 的 Singularity™ Cloud, 例如, 可透過單一主控台涵蓋 AWS, Azure, GCP, Oracle Cloud Infrastructure (OCI) 和 Alibaba Cloud.

評估容器與 Kubernetes 的涵蓋範圍: 服務供應商使用的 CNAPP 是否涵蓋您的 Kubernetes 叢集, 容器登錄庫及無伺服器函式? 確認哪些資料會離開您的環境, 資料儲存於何處, 以及服務供應商的架構是否符合您的法規要求.

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

託管式 CNAPP 的挑戰與限制

將雲端原生安全營運委外，即使合作運作順暢，仍會帶來持續存在的結構性限制。

直接可見性降低。 當供應商代為操作您的 CNAPP，您的團隊便無法直接接觸原始發現。卡內基美隆大學的軟體工程研究所 (SEI) 記錄了這項風險：組織將雲端資產與營運作業委外後，會失去對它們的可見性與控制權。若要重新掌握，必須透過監控與分析，補足過去由內部部署網路日誌提供的資訊。
責任界線不明。 這也涉及共同責任模型：託管服務供應商在您的責任範圍內執行作業，而您的組織仍須對雲端服務供應商與監管機關負責。
依賴供應商與供應商鎖定。非標準資料格式、專有 API，以及對供應商專用工具的依賴，都會讓轉換供應商的成本與工作量高於最初預期。
供應商帶來的供應鏈風險。授予第三方對您雲端環境的作業存取權，本身就是必須管理的風險。英國 NCSC 指出，未受控且未受監控的第三方存取是應避免的做法：一旦將管理或營運職能委外，系統安全就仰賴另一個組織。請限制這類存取權。明定範圍界線、監控供應商活動，並持續審查其人員、流程與技術。
從警示到採取行動的交接延遲。 每項需要您團隊採取行動的發現，都必須經過供應商的分流與派送流程。這項交接可能延誤修復。
快速變動環境中的涵蓋範圍落差。新帳戶、工作負載或服務可能在兩次納管作業之間出現，而供應商的涵蓋範圍仍反映上次整合檢查點時的環境設定。

這些都是已知的失效模式。既然已知，就能預先設計應對方式。以下做法能在造成損失前補上缺口。

託管式 CNAPP 最佳實務

成效穩健的合作模式有幾項共同的營運習慣。每一項都能化解可能使委外安全工作停滯的失效模式。

在供應商派送第一項發現之前，以書面明定共同責任界線。若未依發現類型指定結案負責人，雙方都以為對方會處理，問題便無法解決。明確分工也能維持您的問責機制：供應商負責營運，您的組織仍須對雲端安全態勢、法規遵循及修復執行負責。

將供應商接入您現有的工作流程。在既有的 IR 作業手冊中，為每種升級處理類型指定內部負責人，讓供應商的發現成為可直接納入現有流程的結構化應變工作。

同時保留您對 CNAPP 主控台及供應商報告的存取權，以便根據供應商提供的數據，獨立驗證其績效。其餘合作事項則依據您定期查核的指標管理：

追蹤合約約定的 SLAs，並按既定週期檢視。沒有人衡量的 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 強化託管式 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® 評測中，它達成 100% 識別率，警示數量減少 88%。

透過 Purple AI™，自然語言威脅獵捕與代理式調查可縮短分析師蒐集證據的時間。IDC 於 2025 年 4 月發布的報告指出，威脅識別速度提升 63%，修復速度提升 55%。供應商可以代您執行所有工作；精簡的內部團隊也能直接操作。

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

Combine evidence-backed risk reduction with autonomous response with the most evolved, AI-powered CNAPP.

Singularity Cloud Security is a CNAPP platform combining agentless cloud security posture management, workload protection, compliance monitoring, graph-based attack path analysis, AI-driven alert triage, and security automation.

The Singularity Operations Center serves as the central hub connecting all modules. The Cloud Native Security dashboard provides a high-level summary of cloud risk exposure, including totals for detected misconfigurations, vulnerabilities, and other exposures. Cloud assets can be onboarded from AWS, Azure, GCP, Oracle Cloud, Alibaba, and other providers.

The Inventory section shows a full breakdown of the cloud environment by asset type, including AI/ML resources such as AWS SageMaker and Azure AI Service. The Compliance dashboard supports out-of-the-box frameworks including PCI, HIPAA, and NIST's AI Risk Management Framework. Compliance scores are calculated as the ratio of passed checks to total checks. Findings can be filtered by Controls, Sub-Controls, and other groupings, and the impact of findings on related compliance frameworks is also shown.

Cloud Native Security is the agentless CNAPP component. It includes an Offensive Security Engine that simulates real-world attacks using benign exploit payloads to produce Verified Exploit Paths, identifying which vulnerabilities and misconfigurations are actually exploitable by outside attackers. For example, a misconfigured EC2 instance exposed to remote code execution via Log4j can be validated by pointing a curl command at the instance to confirm the vulnerability is reachable. The same curl command can be used to verify remediation.

The Graph Explorer provides a visual representation of the full attack path, mapping exposures and alerts to connected cloud assets for blast radius and root cause analysis. In the Log4j example, the graph shows the exposed EC2 instance and any alerts triggered as a result, including alerts from the Cloud Workload Security agent. The graph reveals that the Log4j exposure led to a crypto mining attack.

Singularity Cloud Workload Security is the agent-based workload protection component, built on eBPF architecture for real-time detection and response across servers, containers, VMs, and serverless containers. It uses multiple AI detection engines to identify known and unknown threats. The crypto mining alert was detected by the Behavioral AI engine.

Alerts are summarized by Purple AI, SentinelOne's agentic AI security analyst, which provides human-readable explanations of alert origin and recommended next steps. In this case, Purple AI identified that malicious xmrig mining software was executed on the EC2 instance. Purple AI's Auto-Triage capability aggregates similar alerts across the SentinelOne community; in this example, over 1,000 similar alerts were reviewed and 99% were confirmed true positives.

The Storyline feature correlates atomic events into a visual sequence illustrating all malicious activity leading to the alert. In this case, the Storyline shows a Java process spawned due to the Log4j exposure, followed by a bash script executed by that Java process, followed by execution of the xmrig mining software.

Available mitigation actions include killing the process, quarantining files, remediating by deleting files and system changes, rolling back to a saved VSS snapshot (Windows only), and blacklisting the file hash. Detection agents can operate in Detect mode, where actions are taken on-demand, or Protect mode, where mitigation actions execute autonomously in real time.

Singularity Hyperautomation is a low-code/no-code security automation component integrated with Singularity Cloud Security. It allows analysts to build remediation workflows triggered by detections. Available workflow actions include locking down network ingress, creating a pull request to modify Terraform code, and creating Jira tickets for findings of specific severities. Hyperautomation supports 100+ out-of-the-box integrations for building custom workflows.

結論

託管式 CNAPP 將雲端原生應用程式保護平台的營運負擔交給供應商，由其代您配置人力，執行監控、分流及修復工作派送。是否委外，取決於團隊人力、所需的涵蓋範圍，以及雲端環境的複雜程度。

成功的合作仰賴明確的責任界線、可衡量的 SLAs、與事件應變工作流程整合，以及持續驗證涵蓋範圍。做好這四件事，委外就不再意味著失去控制權。您劃定界線、掌握治理，也不必再親自於凌晨 3 點分流警示。

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

常見問題

什麼是代管式 CNAPP?

代管式 CNAPP 是由服務供應商代您營運雲端原生應用程式防護平台的服務模式. 供應商負責跨雲端環境持續管理安全態勢、修正錯誤設定、分流警報, 並回應執行階段威脅.

您仍保有事件升級決策的治理權, 並對修復工作的執行負責. 這種模式將營運 CNAPP 的工作交給外部雲端安全專家, 包括配置分析人員及持續調整偵測結果.

代管式 CNAPP 與代管式雲端安全有何不同?

代管式雲端安全是更廣泛的類別, 涵蓋所有外包的雲端安全工作. 代管式 CNAPP 是其中一種形式, 核心是由供應商營運的 CNAPP. 評估代管式雲端安全供應商時, 請詢問其使用哪個平台及涵蓋範圍.

代管式 CNAPP 與 MDR 有何不同?

代管式 CNAPP 透過供應商營運的 CNAPP, 涵蓋雲端安全態勢、工作負載、身分及 Kubernetes. MDR 著重於偵測和回應進行中的威脅. 代管式 CNAPP 在攻擊發生前降低暴露風險, 而 MDR 在攻擊發生時進行回應. 許多雲端團隊同時採用兩者.

代管式 CNAPP 如何計價?

價格通常取決於受保護環境的規模: 已連接的雲端帳戶數量、受保護的工作負載數量或已掃描的資產數量, 並常採分級訂閱制.

服務涵蓋時段和服務深度也會影響價格, 因為全天候涵蓋與完整調查的成本高於營業時間內的警報分流. 請供應商依其將監控的具體帳戶和工作負載報價, 讓報價反映您的實際環境.

代管式 CNAPP 的導入需要多久?

透過雲端供應商 API 以無代理程式方式連接雲端帳戶, 數小時內即可取得安全態勢與權限的可視性, 因為無須在工作負載上安裝軟體. 若要涵蓋 Kubernetes 及容器或 VM 工作負載的執行階段, 則需部署代理程式或感測器.

較耗時的是調整工作: 篩除誤報, 並將事件升級流程對應至貴組織的負責人, 這些工作會在最初幾週逐步完成. 完整涵蓋取決於是否連接所有帳戶, 包括開發與預備環境.

代管式 CNAPP 服務如何處理多雲環境?

代管式 CNAPP 供應商透過雲端供應商 API 連接各個雲端環境. 代管式 CNAPP 供應商可統一掌握所有已連接帳戶的安全態勢、權限及工作負載防護.

CIEM 分析涵蓋不同供應商的身分模型, 標示不一致的信任邊界及過高的權限. 應定期稽核涵蓋範圍, 確認供應商的監控範圍跟得上各區域新增的帳戶與工作負載.

代管式 CNAPP 會取代您的內部安全團隊嗎?

不會. 代管式 CNAPP 供應商負責雲端原生應用程式防護平台的日常營運, 包括監控、警報分流及轉交偵測結果, 而貴組織保有治理權並負責執行修復工作. 您仍須對自身的雲端安全態勢及法規遵循負責.

這種模式為精簡的團隊增添營運能力與雲端原生專業知識, 同時讓安全成果的責任留在貴組織內部.

如何選擇代管式 CNAPP 供應商?

先確認涵蓋範圍: 供應商涵蓋哪些帳戶、雲端環境及 Kubernetes 叢集. 接著檢視 SLA 中的回應時間、服務涵蓋時段及事件升級機制. 確認誰負責修復、供應商需要哪些存取權限, 以及您的資料儲存於何處. 請求取得管理主控台的存取權限, 以便核實供應商提供的數據.

託管式 CNAPP: 將雲原生安全營運委外

重點摘要