6-1 了解可能存在的风险 · 波仔的云计算课

📄 一句话概括

上云之后，【风险】这个词其实指两类完全不同的东西：一类是它不转了（可用性），一类是它被别人拿走了（安全性）。教材把这两类并排放在本章第一条，是因为它们的对策思路完全相反——前者要多准备一份，后者要少给一点权。而夹在中间、最容易出事的是第三件事：责任被切开之后，那条缝归谁管。

📝 本节和前面几节的关系

前五章一路讲的是【云是什么、怎么搭、靠什么转、卖给了谁】——都是让它变得更好的事。从这一节开始换一个方向：它会怎么坏。

它直接接着利用云服务的注意事项（看得见的地方）与利用云服务的注意事项（看不太见的地方）那两条线——那两节讲的是【客户该注意什么】，这一章换成云服务商与客户各管什么，并且把它系统化成了安全的一整套对策。

一、风险分两类，对策完全相反

先看一个容易混的地方：我们说【云有风险】的时候，说的其实是两件不同的事。

一类是它不转了：机房断电、区域故障、配置改错——服务停了，但东西还在。
一类是它被别人拿走了：数据泄露、账号被盗、系统被植入——服务还在跑，但已经在替别人干活了。

为什么必须分开看：因为对策的方向正好相反。

风险	一句话	主要对策	对策的方向
可用性	它不转了	冗余、多区域、备份	多准备一份
安全性	它被拿走了	加密、最小权限、认证	少给一点权

前者靠【加法】，后者靠【减法】。 一个系统如果只做加法（到处多存一份），暴露面会越铺越大；如果只做减法（什么都锁死），可用性又会掉下去。所以真正的安全工作，是在这两者之间找平衡——这也是本章十节一直在做的事。

二、动手 Demo：服务停止与安全性治理

看到什么算成功：

==================================================================================================
【Demo 1】了解可能存在的风险：服务停止与安全性治理
==================================================================================================
  上云之后，【风险】这个词其实指两类完全不同的东西：
  一类是【它不转了】（可用性），一类是【它被别人拿走了】（安全性）。
  教材把这两类并排放在第一节，是因为它们的对策思路完全不同。

  【一】服务停止：可用性写成几个 9，代价就是一年停多久

  一年 = 365 天 = 8760 小时

  可用性      一年允许停机        直观感受
  ------------------------------------------------------------------
  99%         87.6 小时           三天半
  99.9%       8.76 小时           一个工作日
  99.95%      4.38 小时           半个工作日
  99.99%      52.6 分钟           一节课
  99.999%     5.26 分钟           泡杯茶

  算法：8760 x (1 - 可用性)。所以每多一个 9，停机时间缩小到十分之一。
  现实里的麻烦是：故障不是均匀洒开的，一次区域级故障就能吃掉整年的额度。

  【二】安全性治理：责任是切开的，不是全给云服务商

  云服务商负责                  客户负责
  ------------------------------------------------------------------
  机房、硬件、网络、虚拟化层    数据本身、账号、访问权限
  平台本体、物理安全、供电      自己装的软件、开出去的端口

  这叫【责任共担模型】：服务商管【云的安全】，客户管【云中的安全】。
  最容易出事的地方，恰恰是两边都以为对方管的那些缝。

  【三】风险按四类清一遍（对策各不同）

  风险类型      典型表现                        主要对策
  ------------------------------------------------------------------------------------
  可用性        服务停止、区域故障              冗余、多区域、备份
  机密性        数据泄露、账号被盗              加密、最小权限、MFA
  完整性        数据被改、系统被植入            校验、审计、不可变备份
  合规性        违反法规、合同违约              认证、审计、日志留存

  一句话：可用性靠【多准备一份】，机密性靠【少给一点权】，
  完整性靠【改没改看得出来】，合规性靠【留得下证据】。

读结果：

第一张表最该看的是【直观感受】那一列。99.9% 听起来已经很厉害了，但它意味着一年里有一个完整工作日是停着的——而这个数字还是【合同承诺值】，不是【实际体验值】。所以看 SLA 不要看几个 9，要把它换算成【一年停多久】，这样才能判断它对你的业务够不够。
第二张表是这一节真正的重点。它写着【安全性治理】——治理这个词的意思是：责任不能含糊，要一条一条划清楚。而下面那句【最容易出事的地方，恰恰是两边都以为对方管的那些缝】，是这一整章反复要讲的东西。
第三张表是把风险清一遍的模板。四类风险的对策方向都不同，而每一类在后面的小节里都会展开：可用性在 6-4（物理架构）与 6-8（补丁）里继续，机密性与完整性在 6-5~6-8（墙、缓冲地带、检测、防病毒）里继续，合规性在 6-2（第三方认证）里继续。

三、那条缝到底在哪

【责任共担】说起来简单，落地的时候最容易含糊的就是那条分界线。举几个真实的缝：

事项	看起来该谁管	实际该谁管
云上的数据泄露	云服务商（东西在它那里）	客户：是客户把存储桶权限配错了
云主机被入侵	客户（是我的机器）	两边：客户没打补丁，服务商没隔离干净
底层虚拟化被攻破	客户（我不懂）	服务商：这是它管的层
谁该开哪些端口	服务商（我买的是服务）	客户：默认安全组是【全拒绝】，开哪个是客户自己的决定

规律很清楚：越靠近【数据】和【配置】的事，越是客户的责任；越靠近【设施】和【平台本体】的事，越是服务商的责任。 而现实中出事最多的，恰好是客户以为【我买的是服务，安全当然是它管】的那一类——存储桶公开、密钥写进代码、管理端口对全网开放。

这也解释了为什么 2-11 要把【SLA 与海外法律】单独拎出来讲：这些都是写在合同里的责任划分，看不懂合同，就不知道自己到底买了什么。

30 秒实验

打开任意一家云服务商的【责任共担模型】说明页（多数叫【Shared Responsibility Model】），做两件事：

找它把责任分成几层（通常会画成一张上下分层的图：设施/硬件/网络/虚拟化/操作系统/应用/数据）。
看它把【补丁】这一项画在哪一层——是服务商打，还是客户打？

做完这个你会发现一个规律：几乎每一家都把补丁画成了【两边一起】——平台自己的补丁服务商打，你装在里面的软件补丁你自己打。这条线之所以每家都画得这么细，正是因为它是出事最多的地方。

常见误区

错误：云服务商通过了 ISO 27001，所以我的数据在云上就安全了。——纠正：认证证明的是【它自己那一半认真做了】，证明不了【你那一半】。 那个认证审计的是它机房、平台、流程；而你的数据权限、账号、配置，它管不着。现实里泄露的数据，绝大多数不是机房被人撬了，而是有人把存储桶设成了公开。所以拿到认证之后，真正该做的事反而更多了：把你的那一半也照着同一条线清一遍。
错误：可用性越高越好，所以应该买 99.999% 的服务。——纠正：每多一个 9，价钱涨的不是一点点。因为它意味着服务商要在冗余、跨区域、人工值守上多堆成倍的钱。正确做法是先问【我停一小时损失多少】——如果一小时损失三千块，为了从 99.9% 提到 99.99% 而多付十倍的钱，是不划算的。先算自己的损失，再决定买几个 9。
错误：风险清点就是列一堆可能出的事。——纠正：清点必须落到【对策】上才有用。本节 Demo 第三张表右边那一列才是重点——同一件事在不同人手里对策完全不同（比如【数据泄露】，技术上是加密，管理上是权限，合同上是责任划分）。只列风险不写对策，等于写了一篇恐怖故事。
错误：责任共担的意思是两边各管一半。——纠正：它不是按【比例】切，而是按【层次】切。 服务商管的是从机房到虚拟化层这一整段（不管有几个客户），客户管的是从操作系统往上到自己数据这一整段。所以它在图上不是左右分开，而是上下分开——看清这张图是上下分层的，就不会再问【这是谁的责任】这种问题了。

自测三问（点开对答案）

1. 为什么同样是【风险】，可用性和安全性的对策方向是相反的？ —— 因为**它们破坏的东西不同**。可用性被破坏是【东西暂时用不了】，所以对策是**多准备一份**（冗余、备份、多区域）——**这是加法**。安全性被破坏是【东西被别人拿走了】，所以对策是**少开一个口子、少给一份权限**——**这是减法**。一个系统如果只做加法，暴露面会越来越大；只做减法，可用性又会掉下来。**所以安全工作的本质，是在这两者之间找平衡**，而不是把其中一边做到极致。 2. 责任共担模型为什么是按【层次】分，不是按【比例】分？ —— 因为**它切的是【谁碰得到】这条线**。从机房、硬件、网络到虚拟化层，这一段**只有服务商碰得到**，客户连门都进不去，所以只能它负责；从操作系统、中间件、应用到你自己的数据，这一段**只有客户碰得到**（服务商不知道你在里面装了什么），所以只能客户负责。**所以这张图一定是上下分层，不是左右各半。** 而最容易含糊的，恰恰是【操作系统】这一层——它两边都碰得到，所以每一家都会在这条线上写很多字。 3. 本节四类风险里，哪一类最容易被忽略？ —— **合规性（违反法规、合同违约）**。因为它**不像前两类那样有直观的【当机画面】或【泄露新闻】**——它出事的形式是**罚款、被暂停资质、客户按合同索赔**，往往几个月后才显形。而且它**没有技术解**，只能靠认证、审计、日志留存这些【管理动作】。本节把它单列出来，就是提醒一件事：**合规不是安全的下游，而是它的一个平行目标**——一个系统可以技术上很安全、但仍然不合规（比如日志留得不够久）。