一、安全设计总论：温室控制系统面临的安全威胁、安全设计原则、安全生命周期模型

各位同行，大家好。我是老张，在嵌入式安全这个行当摸爬滚打了十几年。今天咱们开始聊温室控制系统的安全设计。说实话，很多人觉得温室嘛，不就是种个菜、调个温，能有什么安全问题？嗯，我刚开始也这么想，直到有一次在项目现场亲眼看到整个温室大棚因为一个传感器被篡改，导致加热系统失控，一夜之间把一棚名贵花卉全烤干了……那损失，真叫人心疼。

所以，安全设计不是锦上添花，是雪中送炭。这一章，咱们把总论讲透。

1.1 温室控制系统面临的安全威胁

温室控制系统说白了就是一个典型的物联网系统。传感器采集数据，控制器做决策，执行器干活。但问题就出在「联网」这两个字上。我把它归纳为四大类威胁：

1.1.1 物理层威胁

这是最容易被忽视的。你想想看，温室大棚在野外，传感器挂在棚架上，执行器泡在水里。我见过最离谱的一次，是农户为了省电，把温湿度传感器的电源线跟灌溉泵的电缆缠在一起，结果泵一启动，传感器直接烧了。物理层的威胁包括：

• 设备篡改：传感器被恶意替换，比如把温度传感器换成固定阻值的假货
• 线缆破坏：老鼠咬断通信线、人为剪断控制线
• 环境干扰：高湿度导致电路板短路、强电磁干扰影响无线通信

1.1.2 网络层威胁

温室系统现在普遍用无线通信，Wi-Fi、LoRa、NB-IoT都有。网络层的威胁，说白了就是「中间人攻击」。攻击者可以：

• 窃听数据：偷看你的温度、湿度、CO₂浓度数据，分析你的种植规律
• 篡改指令：把「关闭加热」改成「开启加热」，或者把「灌溉10分钟」改成「灌溉10小时」
• 拒绝服务：发送大量垃圾数据，让控制器死机，或者让通信链路瘫痪

我记得有个案例，某大型温室基地的LoRa网关被攻击者用大功率设备干扰，导致整个园区3天无法远程控制，最后只能人工手动操作，累坏了几个技术员。

1.1.3 应用层威胁

这一层跟软件相关。比如：

• 固件逆向：攻击者从设备中读出固件，分析出通信协议和加密密钥
• 越权访问：普通操作员拿到了管理员权限，乱改控制参数
• 数据篡改：历史数据被修改，导致后续的决策模型出错

1.2 安全设计原则

搞安全设计，不能拍脑袋。我总结了五个原则，都是这些年踩坑踩出来的经验。

1.2.1 纵深防御原则

说白了就是「别把所有鸡蛋放在一个篮子里」。单靠一个密码、一个防火墙，那是纸糊的。纵深防御要求：

• 物理层有防拆开关，一旦外壳被打开，立即擦除密钥
• 网络层有加密通信，即使数据被截获，也读不懂
• 应用层有权限分级，操作员只能看数据，不能改参数

我做过一个项目，客户说「我们有防火墙就够了」。结果呢？内部人员用U盘拷走了固件，逆向出了所有协议。嗯，从那以后，我再也不信「单点防御」了。

1.2.2 最小权限原则

每个模块、每个用户，只给刚刚够用的权限。比如：

• 传感器只负责发数据，不能接收控制指令
• 执行器只接收指令，不能修改自己的固件
• 操作员只能操作自己负责的温室，不能越界

你想想看，如果每个传感器都能接收远程升级指令，那攻击者只要攻破一个传感器，就能给所有传感器下发恶意固件。这多可怕？

1.2.3 默认安全原则

设备出厂时，默认状态就应该是安全的。我见过太多设备，出厂时密码是「admin/admin」，或者默认开启所有端口。用户拿到手，如果不改配置，就是裸奔。

正确的做法是：

• 默认密码必须强制修改，不改不让用
• 默认关闭所有不必要的服务，比如Telnet、FTP
• 默认开启安全日志，记录所有操作

1.2.4 失效安全原则

系统出故障时，要进入安全状态，而不是失控状态。比如：

• 通信中断时，控制器应该保持当前状态，或者进入手动模式，而不是乱发指令
• 传感器故障时，系统应该报警并切换到备用传感器，而不是用错误数据继续控制
• 电源掉电时，执行器应该自动关闭，防止突然上电导致误动作

我记得有个项目，温室的风机控制器在通信中断后，默认执行了「全速开启」指令，结果大棚内温度骤降，冻坏了一批幼苗。这就是典型的「失效不安全」。

1.2.5 可审计原则

所有操作都要有记录，出了问题能追溯。包括：

• 谁在什么时间修改了什么参数
• 哪个传感器在什么时间发送了什么数据
• 系统在什么时间触发了什么报警

日志要加密存储，防止被篡改。我建议用区块链的思路，把日志哈希值上链，这样谁想改都改不了。

1.3 安全生命周期模型

安全不是一次性的工作，它贯穿产品的整个生命周期。我习惯用下面这个模型：

这个模型，说白了就是「从摇篮到坟墓」的安全管理。每个阶段都有对应的安全活动，缺一不可。

好，这一章就聊到这儿。下一章咱们深入讲讲「威胁建模与风险评估」，到时候我会拿一个真实的温室项目案例来拆解，看看攻击者到底是怎么一步步攻破系统的。咱们下章见。