4、网络安全架构：网络分段与隔离、防火墙策略设计、入侵检测与防御系统、安全网关与反向代理配置
聊到网络安全架构，我脑子里第一个蹦出来的词就是「隔离」。说白了，安全的核心就是让不该碰的人碰不到，让不该流的数据流不过去。我在做流程自动化系统的时候，最怕的就是整个网络像一个大平层——谁都能串门，那不出事才怪。
4.1 网络分段与隔离：VLAN 与微隔离
网络分段这件事，我个人的习惯是「能切多细就切多细」。你想想看，一个自动化产线里，PLC、SCADA、MES、数据库全在一个广播域里跑，那跟裸奔有什么区别？
4.1.1 VLAN 的传统隔离
VLAN 是最基础的手段。通过 802.1Q 协议，把一个物理交换机切成多个逻辑网络。比如我把控制层（PLC）划到 VLAN 10，监控层（SCADA）划到 VLAN 20，管理层（MES）划到 VLAN 30。
# 交换机上的典型配置示例
vlan 10
name CONTROL-PLC
vlan 20
name SCADA
vlan 30
name MES
interface GigabitEthernet0/1
switchport mode access
switchport access vlan 10
interface GigabitEthernet0/2
switchport mode trunk
switchport trunk allowed vlan 10,20,30嗯，这里要注意：VLAN 只是二层隔离，三层路由还是通的。如果你不配 ACL（访问控制列表），VLAN 之间照样能互访。我曾经见过一个项目，VLAN 划了十几段，结果路由全放开，等于白干。
4.1.2 微隔离：更细粒度的东西向防护
微隔离是我近几年越来越依赖的技术。它不依赖 IP 地址，而是基于工作负载的身份来做策略。比如在 Kubernetes 环境里，我可以用网络策略（NetworkPolicy）来限制 Pod 之间的通信。
核心思路： 微隔离解决的是「东西向流量」的安全问题。传统防火墙只能管南北向（进出数据中心），但攻击者一旦打进内部，横向移动才是真正的噩梦。
# Kubernetes NetworkPolicy 示例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-except-db
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 3306这个策略的意思是：只有打了 app: frontend 标签的 Pod 才能访问数据库 Pod 的 3306 端口。其他的一律拒绝。我在项目中遇到过，有人把数据库直接暴露给整个集群，结果一个被攻陷的容器就成了跳板。微隔离就是用来堵这种洞的。
避坑指南： 我曾经在实施微隔离时，策略写得太严，结果监控系统连不上数据库，告警全炸了。建议先开启「审计模式」跑一周，看看哪些流量是正常的，再转成「强制模式」。
4.2 防火墙策略设计
防火墙策略设计，说白了就是「白名单思维」。默认拒绝一切，只放行明确允许的流量。我见过太多人图省事，直接配一条 permit ip any any，那还要防火墙干嘛？
4.2.1 策略设计原则
- 最小权限： 只开放必要的端口和协议。比如 PLC 只需要 102/TCP（S7 协议），就别开 SSH。
- 双向控制： 不光要管入站，出站也要管。很多攻击是靠 C2 回连的，出站不控等于白搭。
- 策略收敛： 定期清理僵尸策略。我见过一个客户的防火墙上有 3000 条规则，其中一半是五年前加的，早没人记得了。
4.2.2 典型策略示例
# 防火墙策略示例（类 Cisco ASA 语法）
access-list OUTSIDE_IN extended permit tcp any host 10.0.1.100 eq 443
access-list OUTSIDE_IN extended deny ip any any
access-list INSIDE_OUT extended permit tcp host 10.0.1.100 any eq 80
access-list INSIDE_OUT extended permit udp host 10.0.1.100 any eq 53
access-list INSIDE_OUT extended deny ip any any你看，第一条只允许外部访问 10.0.1.100 的 443 端口（HTTPS），其他全拒绝。内部也只允许这台服务器去访问外网的 80 和 53 端口。这样就算这台机器被攻破，攻击者也很难用它做跳板去攻击别处。
警告： 防火墙策略一定要做变更管理。我有个血的教训：半夜改了一条策略，结果第二天产线全停了，因为不小心把 PLC 的通信端口给封了。从那以后，我坚持所有策略变更必须走审批+灰度发布。
4.3 入侵检测与防御系统（IDS/IPS）
IDS 和 IPS，一个是「看门狗」，一个是「看门狗+咬人」。IDS 只告警不拦截，IPS 直接动手阻断。我个人更倾向于 IPS，但前提是你得把规则调好，否则误封能把运维逼疯。
4.3.1 部署位置
| 部署位置 | 作用 | 我常用的方案 |
|---|---|---|
| 核心交换机旁路 | 监控东西向流量 | Zeek + Suricata |
| 互联网出口 | 检测南北向攻击 | 商业 IPS 设备 |
| DMZ 区域 | 保护对外服务 | WAF + IPS 联动 |
4.3.2 规则调优经验
我记得刚接触 Snort 的时候，直接加载了所有规则，结果一天告警 10 万条，根本看不过来。后来我学乖了：先关掉所有规则，只开启跟业务相关的。比如自动化系统里，重点监控 Modbus、S7、Profinet 这些工控协议的异常流量。
# Suricata 自定义规则示例
alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (
msg:"PLC 尝试访问外网 HTTP - 可疑行为";
flow:to_server;
sid:1000001;
rev:1;
)这条规则的意思是：如果内网的 PLC 设备主动去访问外网的 80 端口，就触发告警。为什么？因为 PLC 正常情况下不应该主动访问互联网，这很可能是被植入了恶意程序。
小技巧： 我建议把 IDS/IPS 的告警接入 SIEM 系统，做关联分析。单点告警可能是误报，但如果同一台设备同时触发了「外连异常」和「凭据爆破」两条规则，那基本可以确定是实锤了。
4.4 安全网关与反向代理配置
安全网关和反向代理，是流程自动化系统对外暴露服务时的「守门员」。我习惯把所有对外服务都藏到反向代理后面，绝不直接暴露后端应用。
4.4.1 反向代理的核心作用
- 隐藏真实 IP： 攻击者只能打到代理，打不到后端。
- SSL 卸载： 证书管理集中到代理层，后端不用操心 HTTPS。
- 访问控制： 可以在代理层做 IP 白名单、频率限制、请求过滤。
4.4.2 Nginx 反向代理配置示例
server {
listen 443 ssl;
server_name api.automation.com;
ssl_certificate /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;
# 只允许特定 IP 段访问
allow 10.0.0.0/8;
allow 172.16.0.0/12;
deny all;
location / {
proxy_pass http://backend:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# 限制请求频率
limit_req zone=api burst=20 nodelay;
}
# 阻止常见攻击路径
location ~* \.(php|asp|aspx|jsp)$ {
deny all;
return 403;
}
}你看，这个配置做了几件事：只允许内网 IP 段访问、限制了请求频率、直接拒绝了 PHP 等脚本文件的访问。我在项目中遇到过，有人把 Tomcat 的管理后台直接暴露在公网上，结果被扫到之后直接 getshell。有了反向代理，至少能多一层防护。
4.4.3 安全网关的补充
安全网关（比如 WAF、API 网关）可以放在反向代理前面，做更深度的检测。比如 SQL 注入、XSS、CSRF 这些 Web 攻击，WAF 能直接拦截掉。
注意： 安全网关和反向代理不要做成单点故障。我建议至少部署两台做高可用，用 Keepalived 做 VIP 漂移。否则网关一挂，整个自动化系统就对外失联了。
好了，这一章的内容就这些。网络分段、防火墙、IDS/IPS、安全网关，这四个东西组合起来，基本能挡住 90% 的常见攻击。剩下的 10%，靠的是人的意识和持续的监控。下一章我们聊聊身份认证与访问控制，那又是另一个有意思的话题。