云安全责任共担模型——SaaS客户需要自己做什么

一、云不是魔法——安全责任不会因为上云而消失
云计算的广泛采用在带来弹性、敏捷性和成本效益的同时,也滋生了一个危险的安全错觉:"数据在云端所以安全由云服务商负责"。这个误解是云安全事件中最常见的根本原因之一。事实上,所有主流云服务商(AWS、Azure、Google Cloud、阿里云)都明确采用"责任共担模型"——云服务商负责"云的安全",而客户负责"云中的安全"。
责任共担模型的核心原理可以概括为一句话:云服务商保护基础设施,客户保护在基础设施之上运行的一切。云服务商的责任包括物理数据中心的安全(电力、冷却、物理访问控制)、网络基础设施的安全、虚拟化层的安全、以及托管服务本身的补丁和配置。客户的责任则是自己构建、部署和管理在云上的应用和数据的安全——包括操作系统和应用程序的补丁管理、网络和防火墙的配置、身份和访问管理、数据加密和备份、安全监控和日志管理。
现实中的云安全事件绝大多数源于客户的失责而非云服务商的问题。一份2026年的云安全报告显示,超过80%的云安全事件根因在于客户侧的配置错误、权限过度授予和未修补的漏洞——这些都属于客户的责任范围。AI SaaS企业的客户尤其容易陷入一个安全认知的陷阱:他们可能认为"我们使用的是宝软数字的AI平台,所以数据安全由平台负责"——但实际上,数据如何导入平台、谁有权访问平台、API密钥如何保管、在平台内生成的AI内容如何处理——这些最终都落在客户自己的安全责任范围内。

二、IaaS PaaS SaaS——三张责任矩阵表
责任共担模型的具体内容随着服务模式的不同而显著变化。越底层的服务模式,客户承担的安全责任越大;越上层的服务,云服务商承担的责任越大——但客户的责任永远不会降为零。
IaaS(基础设施即服务)模式下,客户承担最大的安全责任。以AWS EC2或阿里云ECS为例:云服务商负责物理数据中心、网络硬件、虚拟化Hypervisor的安全;客户负责虚拟机的操作系统(包括安全补丁、安全基线配置)、所有安装的应用程序和中间件、网络配置(VPC、安全组、NACL)、身份和访问管理(IAM策略和密钥管理)、数据加密和备份。IaaS模式下有一个形象的比喻——云服务商提供了一间毛坯房(坚固的外墙、安全的大门、防火系统),但房内的所有装修、门锁、监控摄像和保险柜都由客户自行负责。
PaaS(平台即服务)模式下,云服务商承担更多的安全责任——包括操作系统、运行时环境和中间件的安全。以数据库即服务(如AWS RDS、阿里云PolarDB)为例:云服务商负责底层硬件、操作系统、数据库软件的安装和补丁、自动备份的底层机制;客户仍需负责数据库的网络安全配置(安全组和IP白名单)、数据库用户和权限管理、传输中和存储中的数据加密策略、数据库审计日志的启用和分析。
SaaS(软件即服务)模式下,云服务商承担最多的安全责任——几乎整个技术栈都由服务商管理和保护。但客户的责任并未消失。以宝软数字EIOS平台这样的AI SaaS为例,平台负责底层基础设施、应用和AI模型的安全——但客户仍需负责:谁有权访问平台的账号和权限分配、API密钥的安全存储和使用、上传到平台的数据的内容安全和合规性、平台输出的AI内容的使用和再分发方式、平台内生成的报告和分析结果的访问控制。

三、SaaS客户最常见的五大安全盲区
基于对大量云安全事件的根因分析,SaaS客户在安全责任上最常见的五大盲区值得每一位CIO和安全负责人审视。
盲区一:身份和访问管理(IAM)的疏忽。许多组织在SaaS平台上沿用用户名加密码的单一认证方式,没有启用多因素认证(MFA);权限分配遵循"能开就开"的原则而非最小权限原则;离职员工的账号没有被及时禁用;服务账号和API密钥长期不轮换。在SaaS模式下,IAM完全属于客户的责任范围——平台提供的MFA功能不使用、角色权限不审计,不能归咎于平台。
盲区二:数据保护策略的缺失。许多组织不清楚自己在SaaS平台中存储了哪些数据、数据的敏感级别是什么、是否有数据应该被删除但一直保留着、是否启用了平台提供的数据加密选项。对于AI SaaS平台,还有一个特殊的维度:上传的训练数据中是否包含不应上传的敏感信息、模型的输出是否被恰当管理。
盲区三:集成安全被忽视。SaaS平台通常通过API与企业其他系统集成——但这些集成往往在安全审查的范围之外。集成的安全风险包括:过度授权的API令牌、未加密的API通信、第三方集成插件的安全脆弱性、集成点成为攻击者横向移动的跳板。
盲区四:日志和监控的缺位。很多组织对SaaS平台的活动日志缺乏监控——异常登录、大量数据导出、权限变更——这些关键操作可能在平台日志中存在但没有人审查。客户不仅需要确保平台提供了足够的日志记录能力,更需要实际使用这些日志进行安全监控。
盲区五:数据驻留和主权被忽略。许多组织在采购SaaS服务时没有充分审视数据存储和处理的地理位置——数据是否存储在合规的本土数据中心、跨境数据传输是否有合法的合规路径、退出平台时数据如何完整导出和安全销毁。

四、云原生的安全控制——从CSPM到CNAPP
面对云环境中的安全责任,企业需要一套云原生的安全管理工具集——这些工具不是传统的安全软件搬到云上,而是为云环境的弹性和动态性专门设计的。
CSPM(云安全态势管理)是云安全的第一道自动防线。CSPM工具持续扫描云环境的配置——S3存储桶是否公开了、安全组是否开放了不必要的端口、IAM策略是否存在过度权限、加密是否启用——将数百条安全最佳实践转化为自动化检查。CSPM的核心价值在于发现配置漂移——一个今天符合安全标准的配置可能在明天因为某次操作而变得不安全,CSPM的持续扫描能力弥补了人工定期检查的间隔漏洞。
CWPP(云工作负载保护平台)专注于保护运行在云上的工作负载——虚拟机、容器和无服务器函数。CWPP覆盖漏洞管理、运行时安全、系统完整性监控和应用程序控制,是传统端点安全产品在云环境中的演进版。
CNAPP(云原生应用保护平台)将CSPM、CWPP、CIEM(云基础设施权利管理)和容器安全整合为一个统一的平台,覆盖从开发到运行的云原生应用全生命周期保护。CNAPP代表了云安全工具从"各自为战"到"统一平台"的趋势——因为在现代的DevOps和云原生实践中,安全不再是部署之后的"附加"层,而必须在代码编写阶段、CI/CD管道中以及运行时环境中贯穿始终。

五、多云的复杂性——责任不因"多云"而转移
现代企业越来越多地采用多云策略——使用来自不同服务商的多个云平台(如阿里云+腾讯云或AWS+Azure),以及混合了多家SaaS产品。多云环境中,安全责任不仅不减轻,反而因多样性和碎片化而显著增加。
多云的第一个挑战是安全模型的不一致性。阿里云和AWS的安全组和IAM模型在概念上相似但具体实现和安全最佳实践各有不同。如果企业的安全团队精通AWS的安全管理但不熟悉阿里云的特定安全配置,他们可能在阿里云的资源上留下安全盲区。
多云的第二个挑战是安全态势的统一可见性。当数据和应用分布在多个云平台时,安全团队需要一个统一的视图来管理安全态势——否则一个扫描结果在AWS Console、一个在阿里云安全中心、一个在SaaS平台的管理后台,任何跨平台的攻击事件都将难以追踪和响应。
多云的第三个挑战是数据的跨境和多云流动。当数据在阿里云中国区和AWS新加坡区之间流动时,除了云服务商各自的安全责任外,客户还必须独立负责数据跨境的合规性。这可能触发多个法域的数据保护法规——《数据安全法》的数据出境评估要求、GDPR的跨境数据传输规则等。

六、EIOS能力:多云环境的统一安全态势管理
宝软数字EIOS平台面向多云和多SaaS环境,提供跨越不同云平台和安全域的统一安全态势管理能力,帮助企业在多云环境中清晰地理解和履行自己的安全责任。
多云统一资产视图是EIOS在多云安全中的基础能力。平台自动发现并持续追踪企业在阿里云、腾讯云、华为云和全球主流云平台上的所有资产——虚拟机、容器、数据库、对象存储、托管服务——并在统一的资产管理视图中展示,同时自动标记每个资产的"责任分界线"——哪些安全层由云服务商负责,哪些由企业自行负责。这个统一的资产视图消除了"不知道某个平台有哪些资源"的资产盲区。
跨云安全基线检查是第二个核心能力。EIOS内置了覆盖主流云平台的安全基线检查规则——AWS Foundational Security Best Practices、Azure Security Benchmark、阿里云安全最佳实践——并支持企业根据自己的安全策略定制合规标准。跨云的统一基线检查确保无论资产部署在哪个云平台,安全标准保持一致。
SaaS安全态势评估是EIOS在多云管理中的独特能力。平台不仅监控IaaS/PaaS资源的安全,还能评估企业使用的SaaS平台的安全态势——包括:登录日志的异常检测(从异常地理位置或设备的SaaS平台登录)、API使用异常监控、数据导出行为告警。平台特别为EIOS自身提供了"安全责任仪表盘"——清晰展示了平台负责的部分和客户需自行确保的领域,让责任共担模型变得可见可执行。
