Windows多媒体站点权限配置：架构师16年实战方案
|
去年六月份那波Windows多媒体站点权限重构，打得挺艰难的。我段位其实不高，就打过十来年系统架构，但那次真被权限模型卡了半个月——主要是NTFS和IIS的ACL继承链总打架，你改完父目录权限，子目录的媒体流访问规则又崩了。外卖送到了去开门那会儿，我还在想是不是得把DACL和SACL拆开写，结果回来发现测试环境又报403了，耳机戴久了耳朵疼，键盘空格键声音都哑了。 那会儿团队里有个刚进来的小伙子，非说应该用组策略硬推权限模板。我原以为他只是没搞过多媒体站点，结果他翻出2008年的微软白皮书，说“你看这上面写着GPPC能覆盖所有继承冲突”。我让他去试试，他真在测试域控上建了条GPO，结果半小时后整个媒体库的MP4全变成500错误——后来查日志才发现，他没关“拒绝覆盖继承”的选项，权限链直接断在C盘根目录了。语音里他一直咳嗽，说“这版本GPPC是不是有bug”，我直接让他回滚，说“优胜劣汰，老方案能活16年总有它的道理”。 说到优胜劣汰，我印象最深的是2012年那波IIS7.5的权限升级。当时我们用WebDAV挂载媒体库，结果发现匿名访问和Windows认证混用时，ACL会随机丢失。我原以为得重写ISAPI过滤器，结果老架构师老张（他退坑三年了，现在开奶茶店）说：“你试试把NTFS权限里的‘创建文件夹/附加数据’拆开，别让IIS的Worker Process同时拿两个权限。”我照做了，发现媒体流上传的稳定性直接从60%提到90%——后来才知道，IIS7.5的Worker Process默认用NETWORK SERVICE账户，这账户对NTFS的“修改”权限是阉割版的，必须单独配“创建文件夹”才能写元数据。这事儿我记了十年，去年重构时第一件事就是检查NTFS权限的细粒度拆分。
文章配图，仅供参考 充电线不够长只能歪着坐那会儿，我突然想起2015年那波HTTPS改造。当时客户要求所有媒体流必须走TLS1.2，结果IIS的SSL绑定和NTFS权限又掐起来了——你绑了443端口，匿名访问的NTFS权限会被自动替换成IIS_IUSRS的专属权限，但多媒体站点又需要本地系统账户（比如Media Player的后台服务）读文件。我原以为得写个权限同步脚本，结果发现IIS管理控制台里有个“加载用户配置文件”的选项，勾上之后，IIS_IUSRS会继承本地系统账户的NTFS权限链。这事儿当时没人知道，我翻了三天微软论坛才找到，现在看，这不就是优胜劣汰？老方案解决不了的问题，新版本藏了个开关就搞定了。回到去年六月份，最头疼的是权限审计。客户要求所有媒体访问必须留日志，包括谁看了什么、看了多久、有没有快进。我原以为用IIS的日志模块就行，结果发现它只记HTTP状态码，不记媒体流的字节范围请求（Range Request）。后来没办法，只能用ETW（Event Tracing for Windows）自己写追踪器，结果ETW的ProviderID和Level配错了，追了两天才发现是“Microsoft-Windows-IIS-Logging”的Level没设成“Verbose”。那会儿室友在旁边煮泡面，我闻着味儿查日志，突然意识到——权限配置这事儿，和打团一样，你光看表面规则没用，得盯底层事件流。就像你玩ADC，不能只看补刀数，得看对面打野的Gank路径和视野盲区。 现在回头看，这16年搞Windows多媒体权限，最稳的方案永远是“最小权限+动态继承”。比如父目录只给“读取”和“执行”，子目录按媒体类型（视频/音频/字幕）动态配“修改”或“删除”；比如用SACL记录所有权限变更，但DACL只放必要的账户；比如用WebDAV时，把NTFS权限和IIS认证拆成两层，外层用Windows认证控访问，内层用NTFS权限控操作。这些方案不是微软文档里写的，是踩了无数坑才总结出来的——就像你玩新英雄，光看技能介绍没用，得被对面打野抓爆三次才知道什么时候该交闪现。 我段位其实不高，这些方案也是听老张他们说的，我也就打了个大概。但有一点我确定——权限配置和版本更新一样，没有“完美方案”，只有“当下最不烂的方案”。就像现在大家都在骂Windows权限模型复杂，但换个角度想，要是它简单，我们这些架构师早失业了。优胜劣汰，活下来的方案，都是被无数次翻盘、被无数个403错误锤出来的。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
