等保2.0扩展要求：云计算、移动互联、物联网、工业控制系统
好啦，聊完通用安全要求，咱们得进入更刺激的部分——扩展要求。
为什么要有扩展要求？说白了就是三种特殊场景：云环境、移动互联、物联网和工业控制系统。这些场景的技术架构跟传统信息系统差异太大，通用要求管不住。
我个人的习惯是：先理解业务场景，再套等保标准。不然你会觉得这些要求很古怪。
3.1 云计算扩展安全要求
云计算这块，我踩过的坑最多。你以为虚拟机跟物理机一样安全？太天真了。
等保2.0对云计算的扩展要求，核心就一句话：谁管理谁负责，但用户的安全责任不能丢。说白了，云服务商和租户之间要划清楚责任边界。
3.1.1 责任共担模型
| 责任层面 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 物理安全 | 云服务商 | 云服务商 | 云服务商 |
| 虚拟化安全 | 云服务商 | 云服务商 | 云服务商 |
| 操作系统安全 | 租户 | 云服务商 | 云服务商 |
| 应用安全 | 租户 | 租户 | 云服务商 |
| 数据安全 | 租户 | 租户 | 租户 |
我记得有一次做等保测评。客户把应用部署在公有云上，结果数据加密完全没做。客户说“云服务商会帮我处理安全的”。我直接告诉他：数据安全的责任永远是租户的，云服务商不背这个锅。
3.1.2 虚拟化安全
虚拟化环境有几个特殊风险：
- 虚拟机逃逸：攻击者从虚拟机跑到宿主机
- 镜像篡改：有人动了基础镜像
- 租户隔离：网络和存储隔离不到位
- 资源滥用：CPU、内存被恶意消耗
等保2.0专门强调云平台要提供镜像完整性校验功能。我在项目中给客户推荐的做法是：每次启动虚拟机前，用哈希校验镜像的签名。
关键要求：云平台必须支持虚拟网络安全隔离，租户之间不能通过二层网络互相访问。这通常靠VxLAN或者VLAN实现。
3.1.3 数据安全
云计算环境的数据安全，我总结了两大类：
- 数据隔离：不同租户的数据要物理或逻辑隔离
- 数据加密：存储加密和传输加密都是硬要求
你想想看，如果两个租户的数据存在同一个数据库里，但加密密钥不同——这就是典型的多租户加密方案。我建议用信封加密：主密钥归云平台管，数据密钥归租户管。
实战建议：如果自己开发加密功能，用AWS KMS或者阿里云KMS就行。别自己搞密钥管理系统，那真的是个大坑。
3.2 移动互联扩展安全要求
移动端的安全，说实话比PC端难做。为什么？因为终端环境不可控。
- 手机可能越狱
- 网络可能被中间人攻击
- App可能被反编译
等保2.0对移动互联的扩展要求，主要围绕移动终端、无线网络、移动应用三个点展开。
3.2.1 移动终端安全
这部分我最有发言权——我曾经在金融SDK开发中做过终端安全防护。核心要求包括：
- 设备身份认证：只有注册过的设备才能接入
- 远程锁定：设备丢失后能远程擦除数据
- 安全审计：记录设备操作日志
我个人习惯要求团队在sdk里加入设备指纹采集功能，也就是收集设备的唯一标识。这套方案可以防止设备被冒充。
3.2.2 无线网络安全
无线网络这块，典型风险包括：Wi-Fi钓鱼、空口窃听、中间人攻击。
等保标准要求：
- 无线网络和业务网络必须逻辑隔离
- 无线通信必须加密（WPA3或更高等级）
- 终端接入前必须认证
避坑提醒：千万不要用共享Wi-Fi做业务传输。我之前见过一个项目，员工用公司Wi-Fi连了内部系统，结果密码被钓鱼Wi-Fi窃取了。现在要求所有移动终端必须通过VPN或者SSL隧道走加密通道。
3.2.3 移动应用安全
这里我重点说两点：代码保护和数据本地存储。
我曾经在SDK里集成过代码混淆加壳的功能。等保要求移动应用必须防反编译、防调试。说白了就是让你的App没那么容易被逆向。
数据本地存储方面，我建议用KeyStore（Android）或Keychain（iOS）来存敏感信息。别用SharedPreferences或者UserDefaults。
3.3 物联网扩展安全要求
物联网这块，搞安全的工程师头都大。因为物联网终端资源受限——CPU弱、内存小、电池不耐用。做加密要算着性能来。
3.3.1 感知层安全
感知层就是传感器、采集器那些设备。它们的安全问题：
- 物理入侵：设备容易被拆开、篡改
- 固件篡改：攻击者可以刷恶意固件
- 数据伪造：传感器数据可以被伪造
等保2.0要求：物联网网关必须对终端设备进行身份认证。我在项目中用的方案是设备证书。每台设备出厂时烧录唯一证书，网关只允许证书匹配的设备接入。
3.3.2 网络层安全
物联网的网络层，通常用MQTT、CoAP这些轻量级协议。它们本身对安全考虑不够。
我的做法是：在MQTT上叠加TLS。但由于物联网设备资源有限，我建议使用ECC（椭圆曲线加密）而不是RSA。ECC可以做到更小的密钥、更快的签名。
我曾经帮一家智能家居公司做安全方案。他们的网关和灯光控制器通信。我要求每条MQTT消息都带时间戳签名，防止重放攻击。
参数对比：ECC 256位密钥的安全性相当于RSA 3072位。对于物联网设备，省CPU就是省电。
3.3.3 应用层安全
物联网应用平台的安全要求，基本和通用要求一致。但有一个特殊点：数据溯源。也就是你能追溯到某个数据是由哪个采集点、什么时间产生的。
我在物联网项目中，要求每条数据记录都带上时间戳、设备ID、签名三个要素。这样即使数据被中间人篡改，也能被检测到。
3.4 工业控制系统扩展安全要求
工控系统，这是最硬核的部分。我以前做银行加密机时接触过工控环境，那里头的设备不能随便重启、不能随便打补丁。为什么呢？因为要保证生产连续性。
3.4.1 边界安全
工控系统最怕什么？来自外网的攻击。震网病毒就是个典型案例。
等保2.0要求工控系统必须与办公网络物理隔离或逻辑隔离。逻辑隔离就是通过防火墙+VPN。但我见过不少老工厂，工控网和办公网就隔了一道交换机，这是大忌。
避坑指南：我曾经给某石化企业做等保测评。他们的PLC（可编程逻辑控制器）直接接在办公网上。我建议用工业防火墙把工控网和办公网隔开。而且还要做白名单过滤——只允许特定IP、特定协议通过。
3.4.2 控制设备安全
PLC、DCS这些控制设备，安全问题包括：
- 固件漏洞：老设备没更新
- 弱密码：很多工控设备出厂密码没改
- 协议风险：Modbus、OPC这些协议没认证
我的建议是：对所有工控设备做端口和服务最小化。只开放必要的端口，跑最小化的服务。
3.4.3 操作员站安全
操作员站就是工人控制机器的地方。这里要关注：
- 身份认证：工人刷卡或指纹登录
- 操作审计：记录谁在什么时间发了什么指令
- 应急响应：发现异常能一键急停
等保2.0要求操作员站必须有双因子认证。我建议用“密码+USBKey”或者“密码+生物特征”。这样即使密码泄露，攻击者也无法远程操控机器。
知识结构总览
看完这四个扩展安全要求，可能觉得内容很分散。我画了一张图帮你把逻辑串起来。
这张图展示了四个扩展安全方向的核心控制点。你可以在做等保合规方案时，对着这张图逐个排查。
实战要点总结
四个扩展安全要求，每个都有自己的难点。我最后给大家归纳三个避坑原则：
- 云计算：责任边界一定要写进合同。云平台只管平台层安全，上层安全是租户的事
- 移动互联：App加固和终端认证不能省
- 物联网：加密方案要考虑设备性能，ECC比RSA更适合
- 工控系统：永远记住生产优先。安全方案不能影响生产连续性，否则没人愿意配合
好啦，扩展要求部分就到这儿。核心思路就是：不同场景不同策略，但底层的安全原则是通用的。再往下走，我们要开始做具体的加密SDK落地了。那个才是真正干货。