文档

安全责任共担模型

更新时间:

ACS集群托管架构遵循责任共担原则,其中阿里云容器计算服务(ACS)负责管理Kubernetes集群控制组件和相关阿里云基础设施的安全性。本文介绍阿里云容器计算服务(ACS)的安全责任共担模型。

术语约定

文档内容将会不可避免的反复用到相同的名称、代码等,为了使文档内容简短、精要,所以在此对一些常用术语进行约定:

  • 平台:即阿里云容器计算服务(ACS)。

  • 客户:使用ACS的阿里云客户。

安全责任划分原则

ACS作为典型的Serverless形式的平台,具备了资源全托管特性,需要明确阿里云和客户之间的安全责任边界,各自守好战场,一般安全责任划分的原则如下:

1. 阿里云的安全责任

阿里云的责任是维护Serverless平台的安全性和可靠性,确保平台的基础设施安全、提供安全的数据存储和处理服务以及保护客户数据的机密性等。阿里云需要确保其基础架构、管理、安全实践的合规性,以保护客户的应用程序不受攻击,同时保护客户数据的隐私性和完整性。

2. 客户的安全责任

客户负责确保其Serverless应用的安全性,涵盖应用程序本身的数据安全性和访问控制、代码编写和审计,以及有效的认证和授权措施等,并且只允许授权的个人或者团队进行访问。

3. 共管资源的安全责任

某些资源无法做到单方面管理及使用,如客户Pod安全组,理想状态是全托管给阿里云,然而有一些客观需求,如客户需要参与管理或希望该资源更受控,这里需要明晰的原则界定:

  • 谁引入风险谁兜底的原则,例如客户创建有安全隐患的Pod或使用被投毒的镜像等,引发故障需要客户自己负责。

  • 各方需要保证最小权限原则,如客户侧开放公网范围过大,那么从这个方向进来的攻击行为及后果,需要客户自行承担;阿里云保证,ACS范围内的Pod安全组,不会扩大访问范围,客户的应用运行不会逃逸出容器。

安全是一个全面的体系,要求阿里云和客户之间的安全责任层次分明,同时保持密切协作。阿里云承担基础设施安全与合规保障的责任,客户则需确保其应用和数据安全。对于责任交叉的灰色区域,阿里云将采取主动策略,确保风险无死角,致力于为客户提供额外安全的Serverless服务支持。

理解责任共担模型

在设计和部署企业应用系统前,您需要明确企业与阿里云各自的安全责任界限。选择阿里云ACS集群,除了管理基础设施,阿里云还会确保Pod的运行环境及相关运行时组件的安全。下图展示了在Serverless架构中使用ACS集群时,阿里云和客户之间安全责任的具体划分。

image

1. 阿里云负责

在管控面侧,阿里云会基于K8s安全基线等业界通用的安全标准,对ACS集群管控面组件进行安全加固,同时面向企业云原生应用生命周期中安全防护的典型场景,提供必要的安全体系概述。在此基础上,阿里云主要负责以下内容:

安全类型

详细内容

基础设施安全性

  • K8s持续升级、CVE漏洞更新。

  • K8s管控链路隔离、网络隔离(如VPC配置,VPC间隧道等)、存储隔离等。

弹性计算资源池安全性

  • 针对容器OS,提供沙箱隔离技术。

  • 针对节点OS,及时提供相关公告并修复漏洞。

集群管控及托管组件安全性

集群鉴权及证书管理、集群内Secret凭据管理、对外暴露端口、VPC隔离及安全组配置的合理性等。

非托管组件和应用市场Chart安全性

提供标准核心配置,保障基本安全问题。

2. 客户负责

在数据面侧,客户的安全运维人员需要负责部署在云上的业务应用安全防护以及云上资源的安全配置和更新。在此基础上,客户主要负责以下内容:

安全类型

详细内容

应用安全性

  • 应用制品供应链、应用运行时安全。

  • 敏感数据涵盖Data in transit 及Data at rest并加密落盘。

  • 基于最小化原则进行账号和角色的授权。

  • 采用云安全中心的应用级安全防控以及时发现并解决潜在的安全隐患。

运维安全性

业务云网络配置、业务云存储配置、业务可观性配置。

业务组件安全性

对于Operator、Webhook等的业务逻辑需要严格限制,以防止影响其他应用的安全。

非托管组件和应用市场Chart的安全性

  • 及时应用阿里云公告中推荐的补丁更新。

  • 遵循安全原则来配置参数,避免因不恰当的设置或权限分配而给攻击者留下漏洞。