责任共担模型的字面意思很清楚，但实践中的误解很普遍。很多企业认为购买了云服务就等于购买了安全，或者认为服务商的合规认证可以覆盖自身业务。实际上服务商的认证证明的是其基础设施符合某些标准，并不代表部署在其上的业务系统安全。
第一，身份与权限。服务商提供身份管理能力，但谁能访问什么资源、权限是否合理，完全由企业决定。
第二，配置安全。安全组规则、存储桶策略、数据库访问白名单、密钥轮换周期，这些配置项的错误是云上事件的主要成因。
第三，数据分类与加密。服务商提供加密能力，但是否启用、密钥由谁管理、哪些数据需要加密，需要企业自行决策。
第四，应用与中间件漏洞。服务商负责底层平台，运行在实例上的操作系统补丁、中间件版本和应用代码由企业负责。
第五，日志与监控。服务商提供日志接口，但是否开启、保留多久、如何分析，是企业自己的事。
第六，供应链与第三方。引入的第三方服务、镜像、组件所带来的风险由企业承担。
第七，合规与通报义务。发生数据泄露时，报送监管、通知用户的责任在企业身上。
建议把它作为云上安全评估的模板，逐项确认责任人、当前状态和差距。对于服务商提供了能力但企业未启用的项目，例如日志审计、静态加密、多因素认证，应优先补齐，因为这类改进成本低、见效快。
第一，对象存储被设置为公开可读，导致数据可直接被下载。第二，安全组或防火墙规则中包含对全网开放的管理端口，尤其是数据库和远程管理服务。第三，访问密钥长期不轮换，且以明文形式写在代码或配置文件中。第四，快照与镜像对外共享，其中可能包含系统盘数据。第五，日志功能未开启或保留时间过短，事件发生后无法追溯。第六，主账号被日常使用，且未启用多因素认证。这些配置问题多数可以通过自动化的配置检查手段定期扫描发现，建议纳入日常巡检。
责任共担不是责任分摊，而是责任划分。把自留风险列清楚，是云上安全治理的第一步。
售后客服
企业微信
