2.3 云服务组件安全考量

2.3 云服务组件安全考量

本节摘要：原则要落到具体资源才算数。本节把云上最常见的四类组件——计算、存储、网络、数据库——逐一拆开，给出每类的安全关键点、典型误配与核对方法，并把它们整理成一张可复用的点检表，作为下一节 IaC 基线的底稿。

四类组件，四张点检表

架构评审往下钻一层，就是组件层面的核对。云的组件种类繁多，但考试与实务中高频出现的就这四类。每类的安全重点不一样：计算类怕失陷后横移，存储类怕暴露与误删，网络类怕通道过宽，数据库类怕凭据泄露与越权查询。点检时按"暴露面、身份、加密、留痕"四个固定维度问，不容易漏。

计算组件（云主机、容器、函数）的核对重点：镜像来源是否可信、补丁谁来打、登录方式是否去掉了密码与静态密钥、元数据服务是否加固。云主机有个独有问题值得单独记：元数据服务里藏着临时凭据，历史上有大量真实入侵就是通过应用漏洞读取元数据、再拿凭据横移的——所以主流云都提供了强制会话令牌校验的加固开关，新环境应当默认打开。

存储组件（对象存储、块存储、文件存储）的核对重点：默认权限是否私有、静态加密是否开启、版本化与防误删是否启用、公开访问有没有整体封禁开关。对象存储是云上数据泄露的第一大来源，很多云现在提供"账户级公开访问封禁"，打开之后任何存储位置都开不了公开权限，一劳永逸——评审时见到没开的，直接列为高优先级发现。

网络组件（虚拟网络、安全组、负载均衡）的核对重点：网段规划有没有按业务敏感度分段、安全组规则是否按最小端口开放、管理端口有没有暴露公网、有没有统一的出口审计。安全组的常见误配是 0.0.0.0 之类全段放行——本节末尾的会话示例里会看到它长什么样。

数据库组件的核对重点：是否强制加密连接、静态加密与密钥归属、审计日志是否开启并外送、账号是否按库表粒度最小化、备份是否隔离存放并定期演练恢复。托管数据库把补丁与高可用交给了厂商，但账号体系、审计配置、备份验证全在客户手里——又一个共享责任的活例子。

会话推演：一次十五分钟的快速点检

点检不需要重型工具，云控制台的查询接口就够。下面是一段典型的点检会话（以某云的通用命令行接口为例，思路可平移到任何平台）：先列出所有对象存储位置及其公开状态，再查安全组里放行全部来源的规则。

# 第一步：盘点公开暴露的存储位置（输出经过简化）
$ cloudtool storage list --query "公开状态=可公开读"
  bucket: edu-video-prod     公开读   创建者: dev-zhang  上次变更: 92天前
  bucket: invoice-archive    公开读   创建者: dev-li      上次变更: 210天前
  [发现] 2 个存储位置公开可读，其中 invoice-archive 存有发票扫描件

# 第二步：盘点安全组里过宽的放行规则
$ cloudtool network sg-rules --query "来源=任意"
  sg-web      入方向  端口443  来源 0.0.0.0/0   （合理：网站对外服务）
  sg-admin    入方向  端口22   来源 0.0.0.0/0   （过宽：管理入口全段放行）
  sg-db       入方向  端口3306 来源 0.0.0.0/0   （严重：数据库直连公网）

# 第三步：核对静态加密默认值
$ cloudtool storage get-config --name invoice-archive
  静态加密: 未启用    版本化: 未启用    访问日志: 未启用
  [发现] 三项全关，属于"三无"存储位置
​

十五分钟点检出三条高危发现：一个存发票的公开存储位置、一个对全互联网开放的数据库端口、一个加密与留痕全关的"三无"桶。这个会话的价值在示范"评审结论必须有证据"——每条发现后面跟着可复核的输出。顺序也有讲究：先查暴露面（最可能正在流血），再查通道，最后查配置默认值。

整改建议按同一顺序给出：invoice-archive 立即改私有并启用加密与访问日志，排查历史访问记录；sg-db 的 3306 端口收回内网，跳板访问走堡垒通道；sg-admin 的 22 端口限定办公网出口地址。整改完成后复跑同一段命令，输出变干净即是修复证据——这也是"可验证的建议"的直接演示。

组件核对表怎么维护

四张点检表不是一次性的，维护方式决定它的寿命。实操建议：把每类组件的核对项写成与平台接口对应的自动检查脚本，纳入定期巡检；每次云平台新功能上线或团队引入新组件类型时，补表并补脚本；点检发现的误配按"是否可脚本化拦截"分类，能拦截的做成上线前的强制卡点，不能拦截的进人工评审清单。

组件间的组合风险

逐类点检之外，还有一类风险藏在组件组合处，逐个看组件都健康、拼在一起就出问题。三类组合值得列入评审的固定检查项。

托管服务之间的信任传递：函数 A 读对象存储、写数据库，函数的执行角色就需要同时持有两者的权限——组合越多，单一角色的权限面越大。修法是按"一个业务动作一个角色"拆分，宁可角色多，不让角色胖（与 5.3 函数安全的原则同源）。

服务端点与管理端点的错配：托管数据库的业务端口锁进了内网，管理端口却默认开着公网——组件安全配置是"按端点"而非"按组件"生效的，点检时要逐端点过，不能只看组件开关。

跨组件的日志断链：每个组件各自有日志，但标识不统一（A 组件记资源 ID，B 组件记名称），出事时拼不出完整链路。修法是给全链路统一关联标识，写入 2.4 的模板基线——这是第六章日志治理在架构期的预埋，图纸阶段改一个字段，运行期省一个取证团队。

组合风险的本质还是那句架构域的老话：系统的安全性不等于组件安全性的最小值，而可能低于最小值——坏组合会放大单点缺陷。

本节要点回顾

• 四类组件各怕各的：计算怕失陷横移、存储怕暴露误删、网络怕通道过宽、数据库怕凭据泄露，按"暴露面、身份、加密、留痕"四维点检不漏项。
• 元数据服务是云主机的独有暗门：临时凭据藏在里面，加固开关应当默认打开。
• 账户级公开访问封禁是一劳永逸的控制：评审见到没开的直接列高优先级。
• 点检结论必须带证据：命令输出比口头承诺可信，整改后复跑同一段命令即是修复验证。
• 组合风险会低于最小值：信任传递、端点错配、日志断链三类组合项列入固定检查。

一个延展之问：点检该多久跑一次

四张点检表的运行频率没有定规，但有判断依据：跑的周期等于"从误配出现到造成损失"的平均窗口。存储误配被自动化扫描工具盯上的速度以分钟计，所以公开暴露类核对项适合日级甚至小时级的机器巡检；权限收敛类问题的恶化以月计，季度人工复核足够；组合风险类（信任传递、日志断链）随架构变更出现，挂到变更评审的时机比挂到日历更准。给频率定级的口诀：暴露面类跑得比攻击者慢就是输，权限类跑得比审计快就行，组合类跟着架构变更走。频率定完写进巡检排程，点检表才算从文档变成系统。

到这里，第二章的前三节完成了"读图—定标—点检"三步。最后一步是把这一切固化下来：下一节 IaC 安全基线演练，把点检表写成机器可执行的模板约束，让基线在资源创建的那一刻自动生效，而不是靠人记忆与自觉。