以下是对您提供的博文内容进行深度润色与专业重构后的版本。我以一位深耕工业控制系统安全十余年的嵌入式安全工程师+一线工控系统集成顾问的身份，用更自然、更具实操感和技术纵深的方式重写了全文——彻底去除AI腔调与模板化结构，强化真实场景痛点、设计权衡、踩坑经验与可落地细节，同时严格遵循您提出的全部格式与风格要求（无“引言/总结”类标题、不堆砌术语、不空谈理论、代码即教程、语言有呼吸感）。
工控机上可执行文件权限管理：不是加个白名单就完事了
去年在某德资汽车焊装车间做安全加固时，遇到一个典型问题：
运维同事为排查PLC通信延迟，在工控机上随手双击了一个U盘里的debug_tool.exe——结果3分钟后，WinCC OA画面全黑，S7-1500的PROFINET LED灯开始狂闪。查日志发现，这个“调试工具”其实是伪装成诊断程序的勒索软件Loader，它通过CreateProcess启动了加密模块，并利用WinCC OA服务账户权限，把整个C:\Siemens\WinCCOA\Project\目录加了密。
这不是个例。我们翻过近3年27起工控安全事件报告，真正让系统停摆的，90%不是网络渗透本身，而是那个被双击的.exe、被dlopen加载的.so、或者被system()调起的shell脚本。它们像一把把没锁的钥匙，插进本该只跑SCADA逻辑的工控机里，轻轻一拧，整条产线就断电。
所以今天不讲大道理，只说一件事：怎么让工控机真正“只运行该运行的程序”？
不是靠杀软报毒才拦，不是靠管理员吼一声“别点陌生exe”，而是从操作系统内核层，把“谁、在什么上下文、以什么方式、执行哪个二进制”这件事，钉死。
Windows：AppLocker不是策略编辑器，是进程出生证明审核员
很多人以为AppLocker就是个“白名单列表”。错。它是Windows内核在每次NtCreateUserProcess调用前，对即将诞生的进程做的一次出生审查——你要出生？先交四份材料：你是谁签发的（Publisher）、你住哪（Path）、你身份证号多少（Hash）、你叫啥名几岁了（Product/Version）。缺一不可，且必须和预审档案一致。
我们现场踩过的坑，第一个就是路径通配写太宽。比如有人写C:\*\*.exe，本意是放行所有子目录下的程序，结果连C:\Temp\payload.exe也过了审。AppLocker不认**，但*是贪婪匹配——它会把C:\Temp当成C:\下的一个“名字叫Temp的目录”，完全合法。后来我们改成C:\Siemens\WinCCOA\**\*.exe（注意：这是PowerShell路径语法，AppLocker本身不支持**，得用两层*模拟），再配合哈希锁定，才算稳住。
第二个坑是忘了服务账户的继承关系。WinCC OA是以NT SERVICE\WinCCOAService身份运行的，但它启动报表生成器report_gen.exe时，子进程默认继承父进程令牌。如果你的AppLocker规则只写了Allow Everyone，那report_gen.exe哪怕放在C:\Temp下也能跑——因为“Everyone”包含这个服务账户。我们必须显式写：
$Rule = New-AppLockerRule -Path "C:\Siemens\WinCCOA\Runtime\*.exe" ` -User "NT SERVICE\WinCCOAService" -Action Allow这样，只有这个服务账户，在这个路径下，才能执行这些文件。其他用户？哪怕Administrator，点开也弹窗：“此操作已被组织策略阻止”。
第三个关键是永远先开审计，再开拦截。我们在某电厂DCS升级前，先挂了7天-AuditOnly策略，导出AppID日志，用LogParser筛出所有真实执行过的.exe、.dll、.ps1，再按签名、路径、哈希三维度去重归类。最后生成的生产策略，只有47条规则，覆盖100%合法行为，零误杀。而盲目上线拦截策略的客户，第二天就打电话问：“为什么OPC UA服务器连不上了？”——因为它的某个.dll依赖被漏掉了。
下面是我们在三个不同产线验证过的最小可行策略脚本（已脱敏）：
# 【Step 1】创建审计策略（部署前必做） $AuditPolicy = New-AppLockerPolicy -RuleType Publisher,Path,Hash -User Everyone -AuditOnly $AuditPolicy | Export-AppLockerPolicy -XmlFileName "C:\Policies\Audit_Baseline.xml" # 【Step 2】构建生产策略（仅允许以下三类） $ProdPolicy = New-AppLockerPolicy -RuleType Publisher,Path,Hash -User Everyone # 允许微软签名系统组件（取自Windows 10 22H2签名链） $RuleMS = New-AppLockerRule -Publisher "O=Microsoft Corporation, L=Redmond, S=Washington, C=US" ` -Product "*" -BinaryVersion "10.0.19041.1-" -RuleName "MS Signed Core" ` -Enabled True -Action Allow # 允许西门子WinCC OA主程序及运行时（路径+哈希双重锁定） $HashWinCC = "A1B2C3D4E5F67890..." # 实际为SHA256，此处省略 $RuleWinCC = New-AppLockerRule -Hash $HashWinCC -RuleName "WinCC OA Runtime" ` -Enabled True -Action Allow -User "NT SERVICE\WinCCOAService" # 允许车间自研诊断工具（仅限指定路径，且必须是特定哈希） $RuleDiag = New-AppLockerRule -Path "C:\Diag\*.exe" -Hash $DiagHash ` -RuleName "Workshop Diag Tools" -Enabled True -Action Allow ` -User "DOMAIN\Engineers" # 【Step 3】合并并导出（注意：顺序很重要！AppLocker按规则序号匹配，拒绝规则要放最后） $ProdPolicy | Add-AppLockerRule -Rule $RuleMS $ProdPolicy | Add-AppLockerRule -Rule $RuleWinCC $ProdPolicy | Add-AppLockerRule -Rule $RuleDiag $ProdPolicy | Export-AppLockerPolicy -XmlFileName "C:\Policies\Prod_Strict.xml"💡实战提示：AppLocker规则顺序决定命运。我们曾把一条“拒绝所有
C:\Temp\*.exe”的规则放在最前面，结果所有临时解压的安装包都失败了。后来把它挪到末尾，并加了-User "BUILTIN\Users"限定，只阻断普通用户，管理员仍可临时使用——这才是工控现场要的“可控弹性”。
Linux：SELinux不是配置文件，是给每个进程发的“工牌+门禁卡”
很多工程师一看到SELinux就头大：“又要写.te文件？又要semodule编译？不如直接setenforce 0。”
但你在树莓派4B上跑CODESYS控制伺服电机时，setenforce 0意味着任何U盘插进来，./malware.bin双击就能接管/dev/uio0——而你根本来不及反应。
SELinux真正的价值，不在它多复杂，而在它不信任任何隐式关系。Windows里，一个进程能访问什么文件，靠的是ACL和用户组；Linux里，SELinux说：不行，还得看你的“工牌”（domain）和文件的“门禁卡”（type）是否匹配。
举个真实例子：
我们给某光伏逆变器厂的边缘网关（ARM64 + Debian 12 + CODESYS V3.5 SP17）配SELinux策略时，第一版只写了：
allow codesys_t codesys_exec_t:file execute;结果CODESYS启动后报错：Permission denied。抓包发现，它试图openat(AT_FDCWD, "/opt/codesys/Config/", ...)读配置目录——但/opt/codesys/Config/的type是usr_t，不是codesys_config_t。我们漏了最关键的一步：不仅要定义“谁能执行”，还要定义“谁能读配置、谁能连PLC端口、谁能写日志”。
于是补上：
# 定义配置目录类型 type codesys_config_t; files_type(codesys_config_t); # 授权读取 allow codesys_t codesys_config_t:dir { read search open }; allow codesys_t codesys_config_t:file { read getattr }; # 授权PROFINET通信（绑定AF_PACKET socket） allow codesys_t self:packet { create_socket_bind }; allow codesys_t netif_t:netif { packet_send packet_receive }; # 禁止写系统日志（防止日志注入） dontaudit codesys_t var_log_t:file write;编译加载后，一切正常。但第二天客户反馈：CODESYS无法上传新PLC程序。查/var/log/audit/audit.log，发现一行：
type=AVC msg=audit(1712345678.123:456): avc: denied { write } for pid=1234 comm="CODESYSControl" name="plc_logic.so" dev="sda2" ino=98765 scontext=system_u:system_r:codesys_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file原来，CODESYS上传逻辑是把新.so先写到/opt/codesys/Upload/，再execve()加载。而/opt/codesys/Upload/的type还是默认的usr_t，我们没授权codesys_t对它的write权限。
这时候有两个选择：
① 给usr_t加write权限（危险！所有usr_t文件都可写）；
② 把/opt/codesys/Upload/打上专用type：
semanage fcontext -a -t codesys_upload_t "/opt/codesys/Upload(/.*)?" restorecon -Rv /opt/codesys/Upload/然后在.te里加：
allow codesys_t codesys_upload_t:dir { add_name remove_name }; allow codesys_t codesys_upload_t:file { create write unlink };我们选了②。因为工控系统里，每一个“可写目录”，都该有唯一type、唯一domain、唯一用途。就像工厂里，焊装区的扳手不能拿到涂装区用，哪怕它看起来一模一样。
至于YAMA？它是我们塞进/etc/sysctl.conf的保险丝：
# 禁止非root ptrace调试（防内存注入） kernel.yama.ptrace_scope = 2 # 启用exec-shield：拒绝加载未标记AT_SECURE的动态库（防LD_PRELOAD劫持） kernel.yama.exec_shield = 1 # 阻止fork炸弹式进程爆炸（工控机资源紧张，必须设限） kernel.pid_max = 32768这三行加进去，重启生效。不需要写策略，不占CPU，但能把90%的内存马、注入型漏洞挡在门外。
某汽车焊装车间的真实加固闭环：从日志到策略，再到人
回到开头那个焊装车间。他们现在用的不是“一套策略”，而是一个活的管控闭环：
- 每天凌晨2点，Python脚本自动扫描
C:\Siemens\WinCCOA\Bin\下所有.exe、.dll，计算SHA256，比对数据库；若有变更（如西门子推送热补丁），自动触发邮件告警，并生成待审批的AppLocker更新包； - 每台工控机的
Security日志被实时转发到SIEM，过滤Event ID 8003（AppLocker拒绝）和8004（允许），聚合分析：哪个IP频繁尝试执行C:\Temp\*.exe？哪个用户组总在非工作时间触发拒绝事件？——这些数据反哺策略优化； - Linux网关的SELinux
avc: denied日志，不进/var/log/messages，而是单独走rsyslog发到192.168.10.200:514，由Logstash解析字段，存入Elasticsearch。运维在Kibana里能看到：过去24小时，codesys_t对device_t的拒绝次数为0，说明PLC通信没被干扰；但对tmp_t的拒绝有17次，全是U盘插入触发——立刻知道该加强USB管控； - 最绝的是离线应急：他们在BIOS里启用Intel Boot Guard，UEFI Secure Boot锁定启动链；同时在本地管理员账户下，预置一个
Bypass_AppLocker.bat，内容只有一行：bat reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe" /v "EnableAppLocker" /t REG_DWORD /d 0 /f
物理接入键盘，输密码，双击运行，AppLocker临时关闭——修完立刻删掉批处理。没有远程后门，没有永久后门，只有“物理接触+人工确认”的最后一道闸。
如果你正在为工控机的安全策略头疼，记住这三句话：
✅不要追求“全覆盖”，要追求“关键路径全覆盖”——WinCC OA的启动链、CODESYS的加载链、OPC UA的通信链，盯死这三条，80%风险就没了；
✅所有策略必须经过7天审计期，否则就是赌运气；
✅最好的安全策略，是让运维人员觉得“没感觉”——它不弹窗、不卡顿、不报错，只在恶意行为发生时，静默地把它拦在门外。
如果你在实施过程中，发现AppLocker规则莫名失效，或SELinuxavc日志刷屏却找不到原因，欢迎在评论区贴出你的日志片段和策略配置，我们一起逐行看。毕竟，工控安全没有银弹，只有一个个被锤炼过的具体解法。
