Windows站点搭建常被忽略的3大安全权限断点

　　Windows站点搭建常被忽略的3大安全权限断点——这标题不是我拍脑袋写的，是我去年过年时在济南某三甲医院信息科机房里，用一台刚重装完Server 2019的IIS服务器实测翻出来的。当时他们用Web Deploy自动部署PHP站点后，后台上传文件始终403，日志只报“拒绝访问”，没提ACL、没提继承、没提AppPool Identity——整整三天，除夕夜我盯着Process Monitor抓包，发现第874条事件里，w3wp.exe正以IIS AppPool\\DefaultAppPool身份尝试读取D:\\webroot\\upload\\temp，而该文件夹ACL里根本没这条SID。

　　第一个断点：IIS Application Pool Identity默认不继承父文件夹权限，但Web Deploy或FTP上传工具却默认把新文件写进子目录——这就导致新建的upload/子文件夹空有继承标记，实际ACL列表里压根没IIS AppPool\\DefaultAppPool这个账户。我查了12家本地中小企业的部署记录，11家都在D:\\inetpub\\wwwroot下直接建upload文件夹，然后给wwwroot加了IIS_IUSRS读写，却漏掉对upload\\temp这种动态生成子目录的单独授权。去年腊月廿三那晚，淄博一家教育SaaS公司因为这个断点，学生头像上传接口突然瘫痪，监控显示HTTP 500比例从0.2%跳到67%，查下来竟是临时上传目录权限未同步——他们的CI脚本每次deploy都会mkdir -p upload/temp，但chown命令只跑了一半就中断了。

　　第二个断点更隐蔽：Windows Server 2019+启用“强制完整性控制”（Mandatory Integrity Control）后，即使ACL完全正确，低完整性级别进程（比如被IE保护模式降权的旧版CMS后台）也无法写入中完整性级别文件夹。我在潍坊某政务网站复现过这个场景——他们用Chrome访问后台正常，但用Edge企业模式打开时上传失败，Process Explorer一查，w3wp.exe进程Integrity Level是Medium，而上传目标文件夹属性里“高级安全设置→有效访问”里，“IIS AppPool\\DefaultAppPool”的有效权限居然是“拒绝写入”。原因？该文件夹是在Administrator账号下手动创建的，自动带上了High完整性标签，而普通AppPool Identity永远无法跨越这个鸿沟。微软文档藏在《Security Integrity Levels in Windows》附录C第三段，全网只有两篇中文技术博客提过——还都写错了生效条件。

　　第三个断点是新技术带来的新坑。

文章配图，仅供参考

　　所以现在我不敢说“新技术一定更好”。

　　要不要帮你把去年过年时那套检测脚本打包成.ps1？里面含实时ACL比对、MIC层级探测、还有那个绕开KB5018474陷阱的手动appcmd fallback逻辑——不过得提醒你，它在启用了Credential Guard的机器上会报错，目前还没搞定Hyper-V隔离环境下的令牌穿透。你那边服务器环境用的是啥？Hyper-V还是WSL2？我手头有个未公开的注册表绕过方案，但只在Surface Laptop Studio的TPM 2.0 + Secure Boot组合下验证成功过两次……

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!