1.2 云安全核心概念与术语

1.2 云安全核心概念与术语

本节摘要：术语是推演的通用语言，说错一个词，责任就切错一次。本节从"云安全就是云厂商的安全"这个流传极广的误解切入，把多租户、共享责任模型、服务模型、控制面与数据面、攻击面五个概念钉牢，并用一套存储桶权限配置把"责任边界"从口号变成可操作的判断。

从一个流传很广的误解说起

先把反面教材摆在桌面上：某团队把业务系统整体搬上云，用了半年后例行安全检查发现，数据库的备份文件存在一个对互联网开放的存储位置里。负责人第一句话是"云平台的安全不是包含在服务费里吗"。这句反问暴露的正是本节要拆的第一个误区——把"云安全"当成"云厂商的安全"。

事实是，云的安全是两家共管：厂商保"云本身的安全"，客户保"云里面内容的安全"。厂商保证机房门禁、物理主机虚拟化层、底层网络设备不出问题；至于你把数据存在哪、给谁开了权限、代码有没有漏洞，厂商既不知道也没义务替你看。误解的代价不是扣分，是真金白银的数据泄露。把这层责任关系讲成一套可执行的规则，就是共享责任模型。

五个核心概念一次钉牢

多租户：同一组物理硬件上跑着许多互不相识客户的负载，靠逻辑隔离划开。它带来云的低价与弹性，也带来云特有的安全命题——隔离一旦失效，邻居就是你的攻击面。理解多租户，才能理解为什么后面章节反复强调虚拟化层安全、租户隔离验证这些议题。

共享责任模型：厂商与客户按服务模型切分安全责任，切分线随服务模型上移而滑动。它是全册使用频率最高的概念，后面数据、平台、应用、合规各章的争论最终都会落回"这条责任在切分线的哪一侧"。

服务模型：IaaS、PaaS、SaaS 三档，区别在于厂商替你接管了哪几层。IaaS 只给你基础资源，操作系统往上都是你的；PaaS 连运行时一起管了，你只负责代码与数据；SaaS 连应用都是现成的，你能管的几乎只剩配置与数据。服务模型选择本质上是责任转移决策：转移得越多，自己的负担越轻，对厂商的信任要求越高。

控制面与数据面：控制面是你下指令的通道（创建资源、改配置、授权），数据面是实际承载业务流量与数据的通道。两者权限体系往往独立，攻击者拿到控制面权限等于拿到整个环境的方向盘——这也是为什么云上凭据泄露比单台主机失陷严重得多。

攻击面：所有可能被攻击者触碰的入口总和。云的弹性让攻击面动态变化：今天上线一个函数、明天开一个 API 网关入口，攻击面就悄悄长了一块。所以云上的攻击面管理必须是持续动作，而不是一年一次的梳理。

图 1-2：共享责任在不同服务模型下的分界线

案例推演：一次存储桶权限事故的责任切分

背景：一家在线教育公司的课程视频存在对象存储里，为了让转码服务读取文件，开发把存储位置设成了公开可读。三个月后安全巡检发现，有境外地址在批量拉取未上线课程。

操作：处置分四步走。第一步立即取消公开读权限，切断数据出口；第二步核查访问日志，圈定泄露范围与时间窗；第三步向上追责查配置变更记录，确认这是一次为赶工绕过审批的直接变更；第四步向前追溯，问为什么公开读是平台允许的默认选项之一、为什么没有配置巡检在第一时间报警。

结果：泄露范围限定在未上线内容，损失可控，但复盘会上拉出了三条整改线——所有存储位置默认私有、变更走工单审批、配置漂移进小时级巡检。

解读：用本节术语重述这场事故——公开读把"数据面"入口直接暴露进了攻击面；变更未审批说明"控制面"权限过宽；巡检缺位说明运营域的控制没有覆盖到配置层。责任的切分也清晰：厂商提供了日志与告警能力，但"要不要用"在客户一侧，这正是共享责任模型里"客户负责数据与访问管理"的具体化。

变式：把场景换两次再推。换成 SaaS 网盘分享链接设成"任何人可查看"，责任完全在客户配置，厂商无责；换成厂商底层存储故障导致私有数据互相可见，责任在厂商一侧。同一套术语，三种局面，责任判定完全不同——考试场景题考的正是这种切换。

把术语变成肌肉记忆

上面的配置例子值得记一辈子，因为它把抽象的责任模型落成了一句可操作的口令：改任何一处配置前，先问"这条配置动了之后，攻击面多了哪块、责任线移到哪侧"。落地到日常，给两条最低配的练习：每周在自家云环境里挑一个存储位置与一个 IAM 策略，用共享责任视角口头复述一遍"谁管什么"；读安全新闻时，试着用控制面、数据面、攻击面三个词复述事件经过，能复述顺，说明术语已经内化。

术语高频混淆对照

本节五个概念在考试与日常里最常被两两混淆，用一张对照表钉死边界。混淆的代价在真实工作里是灾难性的：把服务模型与责任模型混为一谈，会签出责任划分完全错位的合同。

用这套判别句自测：同事说"我们上了云厂商的托管数据库，所以数据库的审计合规是厂商的责任"——这句话错在哪？错在把"托管的组件运维"扩大成了"合规问责"，审计配置与合规举证仍在客户侧，共享责任模型从未把问责转移出去。

一个综合场景把五个概念串起来

场景：一家公司用 SaaS 客服系统处理用户咨询，客服系统通过 API 从自家 PaaS 环境的用户数据库拉取用户资料做来电弹屏。

逐概念过一遍：这是 SaaS 与 PaaS 的混部，责任切分线有两层——SaaS 侧客户负责账号与配置，PaaS 侧客户负责代码与数据；用户资料从 PaaS 流向 SaaS，数据面跨过了组织边界；控制面上，SaaS 的管理员账号若开了全员共享，任何人都能改数据流向配置，控制面权限过宽；攻击面上，这个集成多出了两个入口——SaaS 到数据库的 API 凭据，以及 SaaS 的员工登录入口；多租户层面，用户资料存在 SaaS 厂商的共享环境里，隔离机制靠厂商审计背书。一道看似普通的集成需求，五个概念各自给出一条待办：API 凭据最小化与轮换、SaaS 账号治理、数据流向审批、厂商隔离验证、访问留痕。

这就是术语学到位的样子：不是背得出定义，而是看到业务动作能自动翻译成一串安全议题。考试场景题的题干密度不高，信息都藏在业务描述里，翻译能力就是解题能力。

本节要点回顾

• 共享责任模型是全册的元规则：责任可以转移执行，不能转移问责；切分线随服务模型上移而滑动，但数据与访问管理永远留在客户一侧。
• 服务模型选择是责任转移决策：从 IaaS 到 SaaS，管得越少、信得越多，合同与尽调的分量就越重。
• 控制面权限的分量远大于体量：拿到控制面凭据等于拿到环境方向盘，凭据保护是平台域的第一优先级。
• 攻击面是动态的：每一次开通服务、每一条集成链路都在改写攻击面，攻击面管理必须是持续动作。
• 术语的价值在翻译：把业务动作自动翻译成一串安全议题，是场景题的解题能力，也是真实岗位的核心产出。

下一节我们把镜头拉远，看这些概念所应对的威胁本身是怎么演化出来的——理解了威胁的来路，控制措施的设计逻辑就不再是需要背诵的条文。