1. 企业云安全架构的边界与目标

企业云安全架构不是一张“安全设备清单”，而是一套围绕云上业务资产、责任分工、合规约束与连续性目标所建立的决策框架。它的第一项工作，是先把“边界”和“目标”说清楚：哪些资产在架构范围内，哪些风险由云服务商承担，哪些必须由企业自己兜底，架构最终要支撑什么样的业务结果。边界不清，后续的选型、控制点设计和验收标准都会失焦。

一、核心对象：架构到底在保护什么

云安全架构的核心对象可以归纳为四类。第一类是云上业务资产，包括虚拟机、容器、Serverless 函数、对象存储桶、数据库实例、消息队列等计算与数据载体。第二类是身份与权限，即云账号、IAM 用户/角色、访问密钥、服务委托关系，这是云环境中最关键的“入口资产”。第三类是数据与密钥，涵盖数据分类分级、加密密钥、证书与凭据。第四类是网络与边界设施，如 VPC、子网、安全组、负载均衡、WAF、专线或 VPN 通道。

这四类对象之间存在明确的依赖关系：身份决定谁能访问网络，网络决定流量能否到达计算资源，计算资源承载数据，数据又依赖密钥保护。架构设计时若只加固其中一层，攻击者往往从相邻层绕过。例如仅配置了安全组，却给实例绑定了过宽的角色权限，攻击者仍可通过实例元数据获取临时凭据横向移动。

二、责任共担模型：边界如何划分

责任共担模型是云安全架构的“地基”。以 IaaS 为例，云服务商负责物理机房、宿主机、虚拟化层和基础网络的安全；企业负责客户操作系统、中间件、应用、数据以及 IAM 配置。到了 PaaS，中间件与运行时由服务商托管，企业责任收缩到应用配置与数据。到了 SaaS，企业主要对自身数据、账号和终端访问负责。

需要特别强调的是：责任共担不等于责任转移。云服务商“负责”物理安全，并不意味着企业可以不做备份；服务商“负责”虚拟化隔离，也不意味着企业可以随意开放管理端口。架构设计中应把每一项控制措施明确标注为“服务商责任”“企业责任”或“共同责任”，并对共同责任部分约定接口与验证方式。

三、合规驱动：架构必须满足的外部约束

合规不是“上线前补材料”，而是架构的输入条件。以国内常见场景为例，等保 2.0 要求云上系统明确安全区域边界、访问控制和审计记录；数据出境场景要求识别数据主体、存储位置和传输路径；金融、医疗等行业还有更细的日志留存与加密要求。这些约束会直接改变架构决策：如果要求数据不出境，就不能把备份桶放在境外区域；如果要求操作留痕，就必须开启云审计并集中存储日志。

实践中建议把合规要求转化为可验证的架构条目。例如“等保三级要求身份鉴别”可转化为“所有管理入口启用 MFA，且 IAM 策略禁止长期密钥”。这样合规检查时可以直接对照配置，而不是临时翻文档。

四、业务连续性：安全与可用的平衡

安全架构不能只追求“防住”，还要保证“活着”。业务连续性要求通常用 RTO（恢复时间目标）和 RPO（恢复点目标）表达。假设某核心交易系统要求 RTO ≤ 30 分钟、RPO ≤ 5 分钟，那么架构上至少需要：数据库跨可用区主备、对象存储开启版本控制、关键配置以基础设施即代码方式保存、定期执行切换演练。安全控制（如加密、访问审批）不能成为恢复路径上的单点阻塞，否则一次密钥丢失就可能让 RTO 目标彻底失效。

五、评价维度：如何判断架构是否合格

建立评价维度，是为了让架构设计从“感觉安全”走向“可度量”。建议至少覆盖六个维度：安全性（控制点覆盖率、漏洞修复时长）、合规性（检查项通过率）、可用性（RTO/RPO 达成情况）、可运维性（告警响应、变更成功率）、成本（安全投入与业务规模匹配度）、可扩展性（新增业务接入所需时间）。

下面给出一份可直接用于架构评审的简化检查表，字段和判断依据均围绕本章边界与目标展开：