Container Compute Service：安全責任共擔模型

術語約定

文檔內容將會不可避免地反覆用到相同的名稱、代碼等，為了使文檔內容簡短、精要，所以在此對一些常用術語進行約定：

• 平台：即容器計算服務ACS。

• 客戶：使用ACS的阿里雲客戶。

安全責任劃分原則

ACS作為典型的Serverless形式的平台，具備了資源全託管特性，需要明確阿里雲和客戶之間的安全責任邊界，各自守好戰場，一般安全責任劃分的原則如下：

1. 阿里雲的安全責任

阿里雲的責任是維護Serverless平台的安全性和可靠性，確保平台的基礎設施安全、提供安全的資料存放區和處理服務以及保護客戶資料的機密性等。阿里雲需要確保其基礎架構、管理、安全實踐的合規性，以保護客戶的應用程式不受攻擊，同時保護客戶資料的隱私性和完整性。

2. 客戶的安全責任

客戶負責確保其Serverless應用的安全性，涵蓋應用程式本身的資料安全性和存取控制、代碼編寫和審計，以及有效認證和授權措施等，並且只允許授權的個人或者團隊進行訪問，主要的原則有：

• 自身引入的安全風險需要負責：部署具有安全隱患的Pod或者授權面過大，影響了業務，需要客戶自行負責。

• 主動申請開放容器特權需要負責：平台預設禁止開放對於容器穩定性和安全有較大影響的特性（例如Privileged和Capabilities等），但是客戶可以通過主動申請流程進行開放，因此如果由於過大的特權導致穩定性和安全問題，例如橫向攻擊叢集內其他Pod，需要客戶自行負責。

3. 共管資源的安全責任

由於平台某些資源無法做到單方面管理及使用，例如客戶的Pod安全性群組，理想的狀態由阿里雲進行全託管。然而有一些客觀需求，客戶想要參與管理或希望該資源更受控，就需要更明晰的原則界定：

• 誰引入風險誰兜底原則：例如客戶建立有安全隱患的Pod或使用被投毒的鏡像等，引發故障需要客戶自行負責；阿里雲保證，ACS範圍內的管控Pod，不會有安全隱患，不會影響客戶業務。

• 各方保證最小許可權原則：如果客戶側開放公網範圍過大，那麼從這個方向進來的攻擊行為及後果，需要客戶自行承擔；阿里雲保證，ACS範圍內的Pod安全性群組，不會擴大存取範圍，客戶的應用運行不會逃逸出容器。

安全是一個全面的體系，要求阿里雲和客戶之間的安全責任層次分明，同時保持密切協作。阿里雲承擔基礎設施安全與合規保障的責任，客戶則需要確保其應用和資料安全。對於責任交叉的灰色地區，阿里雲將採取主動策略，確保風險無死角，致力於為客戶提供額外安全的Serverless服務支援。

理解責任共擔模型

在設計和部署公司專屬應用程式系統前，您需要明確企業與阿里雲各自的安全責任界限。選擇阿里雲ACS叢集，除了管理基礎設施，阿里雲還會確保Pod的運行環境及相關運行時組件的安全。下圖展示了在Serverless架構中使用ACS叢集時，阿里雲和客戶之間安全責任的具體劃分。

1. 阿里雲負責

在管控面側，阿里雲會基於K8s安全基準等業界通用的安全標準，對ACS叢集管控面組件進行安全強化，同時面向企業雲原生應用生命週期中安全防護的典型情境，提供必要的安全體系概述。在此基礎上，阿里雲主要負責以下內容：

2. 客戶負責

在資料面側，客戶的安全營運人員需要負責部署在雲上的業務應用安全防護以及雲上資源的安全配置和更新。在此基礎上，客戶主要負責以下內容：