6.5 云、容器与物联网安全

6.5 云、容器与物联网安全

本节摘要：云安全的核心是责任共担模型（Shared Responsibility Model）——云商负责"云本身"的安全，客户负责"云上之物"的安全，服务模型（IaaS/PaaS/SaaS）越靠上层客户的责任越少；容器安全把责任细化到镜像、运行时与编排三层；物联网安全的症结是海量弱终端长期不更新。本节鉴定三个新战场的边界改写与防御落点。承接 6.4 节的运营引擎，本节把它们的适用对象扩展到边界之外的新形态。

边界模糊之后，责任先模糊了

传统架构里"你的服务器"物理上长在你的机房，责任天然清晰。上云之后，第一件让人头晕的事就是：配置错误导致的数据泄露，算谁的？答案是责任共担模型的分界线：云商对"云"负责（机房的物理安全、底层虚拟化的隔离、硬件与基础网络），客户对"云上的使用"负责（开在公网的存储桶、过宽的 IAM 策略、应用代码里的漏洞、数据的分类分级）。这条线不是法律修辞，是两家共同签署的服务协议条款。

历年云上重大泄露事件的根因分布高度一致：绝大多数不是云平台被攻破，而是客户侧的配置错误——公开的对象存储、裸奔的管理接口、过宽的访问密钥。换句话说，云商把自己那半边做得很好，出事的都是客户没做的这半边。理解这一点，云安全的工作清单就清晰了。

验明正身：三种服务模型的责任刻度

责任共担不是一条固定线，它随服务模型滑动——买的基础设施越"整机"，客户担的越多：

责任刻度(自下而上, 客户责任递减):
  自建机房    客户负责: 全部 —— 从机房空调到应用代码
  IaaS       客户负责: 系统、应用、数据、配置; 云商负责: 底层硬件与虚拟化
  PaaS       客户负责: 应用与数据、访问配置;  云商接管: 运行环境与中间件
  SaaS       客户负责: 账号、权限、数据使用; 云商接管: 几乎全部技术栈
  记法: 越上层越省心, 但"账号权限与数据"在任何一层都甩不掉 —— 那是客户的永久责任
​

图 6-3 责任共担模型分层图

验明正身：容器与物联网

容器安全把责任再细切成三段。镜像层遵循"谁构建谁负责"——基础镜像带漏洞、依赖带后门，构建者负责扫与修（镜像扫描进 6.6 节的流水线）；运行时段归平台（内核隔离、资源限制，普通用户信任云商的托管服务即可）；编排配置归使用方——Kubernetes 的权限配置是最新的重灾区：容器默认能拿过大的集群权限、特权容器、挂载敏感目录，每一项都能把单容器失陷放大成集群失陷。

物联网安全的病理与两者不同：终端太弱且不可更新。海量摄像头、传感器、门禁跑着裁剪系统，没有补丁通道、默认口令泛滥、算力跑不动加密。这决定了防御重心必须后移——别指望守住终端，守住终端的邻居：IoT 设备一律隔离进专用网络区（5.1 节的安全域思想直接套用），只放行它必需的最小通信，出口流量做行为基线（一台摄像头突然往外传大流量，不用懂它的固件也能判断出事）。把"守不住的东西"圈起来盯着，比假装能守住它诚实得多。

工程实践要点

云配置审计自动化。 责任共担的客户半边，主要风险是配置漂移：今天合规的存储桶，下个月被某次"临时调试"改成公开。用云商提供的配置审计服务定规则（禁止公开桶、禁止 0.0.0.0 放行管理端口），违规自动告警加自动纠正，是性价比最高的一项云上建设。

容器镜像从构建源头管。 运行时发现镜像有漏洞已经太晚（可能已在跑）。镜像扫描挂在构建流水线上（6.6 节），高危不出道，加上镜像签名确保"跑的是构建过的那个"，两端合起来才闭环。

⚠️ 常见坑：给 IoT 设备的隔离区开互联网直连。为了远程运维方便给摄像头做端口映射，等于给全世界留了入口。远程管理走 5.3 节的零信任入口或 5.2 节的加密隧道，映射端口这一形态本身就该被禁止。

💡 关键直觉：三个新战场共享同一个认知转换——防御对象从"我建的系统"扩展到"我用的服务与我买来的设备"。责任可以共担，后果不会共担：出事时监管与用户只认你。

鉴定结论

• 责任共担的分界线随服务模型滑动，"账号、权限、数据"三件是客户在任何模型下都甩不掉的永久责任；
• 容器按镜像、运行时、编排三段认领责任，编排权限配置是当前放大失陷的主要缝隙；
• 物联网终端守不住，防御重心后移到网络隔离与行为基线；
• 新战场的第一批展品过堂。下一节回到软件本身：安全怎么被"生产"出来而非"补"出来——安全开发生命周期。

附卷：一次云上配置审计的发现清单

拿一次真实的配置审计（脱敏改写）看云上"客户那半边责任"漏在哪里：

发现一: 三个对象存储桶可公开读取, 其中一个含用户上传凭证照片
发现二: 一把访问密钥写在前端代码仓库的提交历史里, 已存在十四个月
发现三: 数据库安全组对全互联网开放 3306, 备注"为了调试方便"
发现四: 某测试环境的 IAM 策略允许读取全部生产桶
发现五: 十七台机器的系统补丁停留在两年前, 属于无人认领的"幽灵资产"
​

五条发现没有一条是云平台的错，全部落在客户责任半区——这正是 6.5 节正文的责任共担判词。逐条处置也各有标准答案：公开桶改私有加前端签名 URL、泄露密钥立即轮换并清历史、调试口子改堡垒通道、跨环境读权砍掉用脱敏副本、幽灵资产要么认领要么销毁。注意发现五：清单外资产是所有发现的温床——6.4 节的漏洞管理和本节的配置审计都只能扫到"知道存在"的东西，幽灵资产活在所有清单之外，活在攻击者的扫描器里。

预防侧把这五类发现写进配置基线（1.3 节的"机器可验收"原则）：公开桶检测、密钥提交扫描、安全组白名单、跨环境读权审批、资产认领限期。基线自动跑，违规自动告警——云上的责任半区就管住了。

物联网的准入清单再补一笔：新设备入网前问四个问题（默认口令改了吗、需要访问哪些地址、固件能更新吗、出故障怎么断电断网）。答不齐四问的设备进隔离区，答齐了也进隔离区——只是隔离策略宽窄不同。6.5 节"守住邻居"的思路，落到操作层就是这张四问清单加一条专用网络区。

附卷二：容器运行时的三道闸门与镜像纪律

容器安全在实践中收敛为三道闸门，逐道盘点：第一道，构建期——镜像扫描挂在流水线上（6.6 节），高危漏洞阻断出道；基础镜像用精简发行版，攻击面从源头减半；镜像签名验证确保"跑的是构建过的那个"。第二道，部署期——容器不以 root 运行、只读根文件系统、去除多余能力位、限制网络策略；这四项是运行时配置的最低卫生标准，编排层的准入控制可以自动拒绝不达标的部署。第三道，运行期——运行时检测盯异常行为（容器里起 shell、挂载敏感路径、访问元数据接口），发现即隔离。三道闸门任何一道拦住，逃逸路径就断一条；一道都没有，容器就是一台"无人安检的行李传送带"。

镜像纪律里最容易松的一条是"谁构建谁负责"的落名：内部共享基础镜像必须有明确属主与更新节奏，否则三个月后没人敢动它——漏洞越积越多，最后大家一起绕过扫描继续用旧版。基础镜像的升级要像依赖升级一样例行化，每月一次小步快跑，好过一年一次大爆炸。

物联网侧把正文的隔离思路落到网络配置上只有三行：专用 VLAN 加默认拒绝、只放行注册过的目的地与端口、出网流量过行为基线。三行配置写进准入模板，新设备接入自动套用——守住邻居不需要懂每台设备，只需要不给它自由。