Sophos Firewall Config Studio V2：它已经不只是一个 Viewer
目录
今年 2 月，Sophos 发布了 Configuration Viewer。这个 tool 终于让 Sophos Firewall 世界里一个长期很痛的点稍微没那么痛了：你可以不再直接面对原始 XML，就能去读、去搜、去 compare 配置。我之前已经在 那篇关于 Sophos Firewall Configuration Viewer 的文章里 写过这个工具。
到了 2026 年 4 月 15 日，Sophos 又往前迈了一步。原来的 Configuration Viewer 现在变成了 Config Studio V2。这个改名很重要，因为它不是简单的 cosmetic update。Sophos 显然已经不再把它当成一个纯 viewer，而是在把它往一个也能 edit 的 browser-based tool 方向推进。
这正是它开始变得有意思的地方。能读是一回事。可在真实的 firewall 运维里，我们几乎总是同时需要三件事：理解、比较、以及干净地修改。
而也正是在这里，我的主要批评开始出现。这个 tool 在很多方面确实不错，但你很难忽视一点：Sophos 再一次把这些能力建设在 actual firewall 之外，也建设在 Sophos Central 和 Firewall Manager 之外。在某些方面，这个外部工具现在已经比 firewall 自己的 UI，甚至比 central management，看起来更现代、更强大。从 admin 的角度看，这其实很难让人舒服。
如果你长期关注 Sophos，这个 pattern 你一定很熟。真正能感知到的 UI 改进总是非常慢。以 admin 的视角来看，连 widescreen monitor 的支持都等了很久。与此同时，老 UTM 在某些方面至今反而更友好，比如它的 change logging 有时更清楚，能更容易看出是谁改了什么。正是这种 quality-of-life 级别的问题，经常一拖就是几年，而每个 release 却更常出现那些写在 vendor slide 上比较好看的功能。
如果你想先看 Sophos 自己的官方概览，这里是视频：
Config Studio V2 到底是什么
Sophos 把 Config Studio V2 描述为一个基于浏览器的 tool，用于查看、分析、比较，以及现在还可以编辑 firewall configurations。乍一看，这像是一个换了名字的新版本。实际上，它已经不只是这样。
官方方向已经很清楚：
- 把单个 configuration 当成完整 report 来读取
- 比较两个 configurations
- 从零开始创建一个新的 configuration
- 直接在 tool 里修改现有 configuration
- 再将结果导出为 XML、TAR、API 或
curl
对我来说，正是在这里，这个工具从“文档辅助工具”变成了“真正的工作工具”。与此同时，它也更清楚地暴露出 Sophos 到现在仍然没有在 firewall 本身和 Central 里解决好的问题。
Sophos 的官方视频也清楚表明，Config Studio V2 已经明显超出了旧 viewer 的范围。视频里展示了这些能力：
- 从空白开始创建新的 configurations
- 导入并编辑现有 XML configurations
- 创建 firewall rules 并调整顺序
- 识别 shadowing，并通过移动或删除 rule 来解决
- 做 bulk changes，例如一次性给很多 rules 开启 logging
- 显示 object references
- 识别 duplicate 或 unused objects
- 从 CSV 以及其他格式批量导入 objects
- 基于 Microsoft JSON 之类的 vendor data 生成 cloud objects
- 重新导出为 XML 或 TAR
这些都不是 gimmick。这些都是实打实的 admin 功能。
为什么它在日常工作里有意义
理论上，我们做 firewall changes 都应该有流程、有 ticket、有双人复核、有测试计划。现实里，你经常会坐在一个 export、一个 diff、一台旧的 secondary firewall，或者一个刚接手的 environment 前面，先花时间去搞清楚：这里到底都做了些什么。
而 Config Studio V2 的价值，恰恰就体现在这里。
用于审计和 review
如果你要接手别人的 Sophos Firewall，web UI 往往不是最佳起点。你会不停点 NAT、firewall rules、objects、interfaces、VPNs 以及各种 special cases，最后在一堆 tab、screenshot 和 notes 中迷失。
一个整理好的 configuration report 会舒服得多。与其在菜单之间来回跳，你会得到一个更连贯的 rules、policies 和 settings 视图。对 review 和 audit 来说，这非常有帮助。
用于 change windows
对我来说，compare 部分甚至更重要。做较大变更时，我不只是想知道“有东西变了”。我想非常清楚地看到：到底新增了什么、删掉了什么、改了什么。
无论是 WAN migration、NAT 重构、VPN 调整，还是对多年累积下来的 rules 做 cleanup，一个好的 diff 都会真正节省时间，也会降低你不小心动到别的东西的风险。
用于 MSP、handover 和 migration
管理很多 firewall，或者需要在团队之间 handover environment 的人，都很熟悉同一个问题：configuration 往往同时存在于很多地方：
- firewall 本身
- ticket 系统里
- spreadsheet 里
- 某个 wiki 里
- 以及最早搭这套东西的那个人脑子里
Config Studio V2 可以稍微缩小这个 gap。它当然不是 good documentation 的替代品，但它是一个明显更好的 handover 和 review 起点。
和旧 viewer 相比，到底变了什么
最初的 Configuration Viewer 本质上是一个读和 diff 的工具。这本身已经很有帮助，因为 Sophos 的 XML 本来就不适合人眼直接阅读。
而到了 V2，真正决定性的变化是：它开始支持 editing。
Sophos 现在已经明确把它叫作 configuration editor。这意味着你不再只能导入并分析 export，而是可以在 tool 内修改配置、再次下载，并在需要时把结果当成 API 或 curl output 使用。
我觉得 API 和 curl output 特别值得关注，不是因为每个 firewall admin 会突然开始全面自动化，而是因为它让 change 更容易被复用、被记录，也更容易接入现有 workflow。
这对那些想让 firewall changes 更可控、更 reproducible，但又不想立刻搭一个完整 infrastructure-as-code 平台的团队尤其有意义。
也正因此，Viewer 改名为 Studio 在我看来多少带着一种信号：Sophos 正在旁路上一步步把这个东西做大。越多功能落在这里，“为什么这些功能不直接进 firewall 或 Sophos Central” 这个问题就会越明显。
实际 workflow 是什么样
好的一点是，入口依然很简单。Config Studio V2 仍然基于导出的 configuration 工作。
1）先导出 configuration
Sophos 依然要求你提供 firewall configuration 中的 Entities.xml。步骤如下：
- 在 WebAdmin 中进入
Backup & firmware > Import export - 导出 full 或 selective configuration
- 解压下载的
API-xxxxxx.tar - 把里面的
Entities.xml上传到 Config Studio
这个细节非常重要，因为社区一开始就注意到了同样的问题：直接输入的不是 TAR 本身，而是解压出来的 Entities.xml。
2）读取 report 或启动 comparison
接下来基本有两个方向：
- 读取并分析一个 configuration
- 比较两个 configurations
对很多 admins 来说，第一种用法本身就已经很有价值了。特别是在你想知道某个 object 到底在哪里被引用、到底有哪些 rule groups 真正存在、或者某个 policy 是怎么构建的时候。
3）现在新增的部分：edit
到了 V2，新增加的就是 editing：修改 configuration、重新下载，并在需要时以 XML、API 或 curl 形式继续使用。
这并不会让 Config Studio 直接变成 firewall UI 的替代品。但它确实明确地把它推向了 change workbench 的方向。
我最看重它的几个使用场景
我觉得 Config Studio V2 在四个 practical use cases 上尤其有意义。
为较大的变更做准备
如果你需要在 maintenance window 之前搞清楚哪些 rules、objects 和 NAT relationships 会变化，那么一份结构化 report 加上 before/after diff，显然比直接盯 XML 和不断切换 UI 更舒服。
Review 已经存在的 rules
很多 Sophos environments 都是几年里一路长出来的。旧 host objects、重复 services、历史 NAT rules、项目遗留物都会留下来。一个能把这些东西整理得更容易读的 tool，不只是帮你做新变更，也非常适合做 cleanup。
交接给其他团队或外部服务商
并不是每一个要 review 配置的人都需要 direct admin access。很多时候，一个干净的 export 或 report 反而是更好的基础。
朝更可复用的 change 方式迈一步
对我来说，API 和 curl output 是 Sophos 想把这件事带去哪里的最清晰信号。它不只是做“可见化”，而是在往更结构化的 configuration work 前进。
这对那些想逐步标准化部分变更、但又不想一下子完全走向 infrastructure as code 的团队来说，很有吸引力。
我认为 SFOS 里直接缺少什么
这里才是我真正的核心批评。
Config Studio V2 越有用，我越觉得其中很多功能本不该是 external 的。如果我们谈的是真正的 admin ergonomics，那么我更希望直接在 SFOS 里看到这些：
- firewall rules 的 bulk editing
- 一次性启用、禁用或移动多条 rules
- 终于把 NAT rules 的 clone 做好
- 批量 rename objects
- 通过 search and replace 调整 host、service 或 FQDN references
- 识别并清理 unused objects
- 识别并合并 duplicates
- 在构建 rules 时直接看见冲突
- clone 或移动整块 rules
- 在 commit changes 之前看到 before/after comparison
- 无需绕道外部 tool 的 bulk object imports
对于较大的环境来说，这会极大改善日常操作。可现实是，我们仍然要走 export、unpack、upload，再导回去这一套。它不是不能用，但绝不优雅。
而且我在这里是有意说得很直接：视频其实已经很清楚地展示了，Sophos 更愿意把有用的 usability features 放进一个单独的浏览器工具，而不是持续认真地 modernize firewall UI 和 Sophos Central。我们到今天还在等一些非常基础的东西，比如像样的 NAT rule clone function。与此同时，conflict detection、bulk editing、object analysis 和 cloud imports 却先进了 Studio。从厂商角度看，这也许更快实现、更容易 whitelist；但从 admin 角度看，这等于制造了一个平行世界：最好用的便利功能，不在你每天真正工作的地方。
所以对我来说，Config Studio 不只是一个新工具，也是一种确认。它像是在说明：Sophos 在 firewall UI 和 Central 这件事上已经停滞太久了。low-hanging fruit 还摆在那里，而一个外部工具却突然把这些本来主平台早就应该解决的问题做得更好。
为什么 import/export 模型目前仍然不能完全说服我
如果只是做快速 review，这个模型还可以。可一旦进入真正的生产变更，从 admin 的角度看，它依然显得有些 awkward。
只要一个 tool 是基于 exported configurations 工作，几个很实际的风险就会立刻出现：
- 你手上的 exported configuration 也许早就过时了
- 多个 admins 可能在并行操作，而 export 已经落后
- 敏感的 firewall data 现在变成了 laptops 或 project folders 里的 files
- 在 analysis、edit 和 re-import 之间可能出现 drift
这并不意味着 Config Studio V2 不好。只是意味着：现在这个 workflow 看起来仍然更像 workaround，而不是最干净的 native solution。
对于 audit 和 planning，它是合适的。对于日常直接管理，我仍然希望更多这类能力直接回到 firewall 里。
从 security 视角看，还有一个点：Sophos 表示处理过程会留在 browser 本地。这本身是好事，也显然比把整份 firewall configuration 上传到某个远端 cloud service 要好得多。但它仍然是一个需要你有意识接受的 trust model。因为这些不是无害文件，它们通常包含 network segments、objects、rules、NAT relationships、VPN definitions，甚至更多 security-relevant data。
让人不舒服的地方，不只是“到底有没有东西发到 Sophos 去”。更大的问题是整个 browser context。你把敏感数据交给一个通过 web 提供的 tool，然后必须信任它下发的 application、本地处理过程、浏览器本身、浏览器扩展、本地缓存，以及这些导出文件在 admin system 上的处理方式。哪怕技术上全部留在本地，它的 trust surface 和 attack surface 也依然和直接集成在 firewall 或 central management 里的功能不同。
所以我认为，更深的 SFOS 或 Sophos Central 集成，才是更干净的路径。这不只是为了便利性，也是因为 roles、approvals、auditability 以及敏感配置数据的处理都可以被放在同一个地方。
视频里还有一点也很关键：目前并不是所有 configuration components 都被完整支持。tool 在 import 时会自己给出提示。你可以删除那些不支持的部分，也可以保留，但它们不会完整显示在 Studio 里。对于一个还在早期扩展阶段的工具来说，这可以理解；但它同样说明，这离真正替代 real admin surface 还差得很远。
这个工具当前的边界在哪里
这个 tool 目前还远远谈不上 perfect。有些点现在仍然缺失，或者还不够干净：
Linked NAT rules 有时会显示成 Any
在官方 feedback thread 里，Sophos 提到 linked NAT rules 在某些情况下目前可能会把 source 或 destination 显示成 Any。原因并不是一个传统意义上的显示 bug，而是 exported XML 本身并不能可靠推导出所有语义。
这很重要，因为如果后续分析——例如 rule quality checks 或 shadowing 判断——建立在这个表示之上，就可能得出误导性结论。
Sophos Central 的 .backup files 目前还不是干净输入
社区里另外一个直接问题是：未来是否会支持加密的 Sophos Central .backup 文件。到目前为止还不支持，因为 Config Studio 是围绕 Entities.xml 构建的，而这类加密 backup 不能直接使用。
对 MSP 来说，这当然会非常有价值。但目前它仍然只是未来版本里值得期待的一个点。
Edge cases 依然会存在
在 release 后的头几天里，就已经出现了一些特殊场景下偏差的反馈。对于一个年轻工具来说，这并不奇怪，也正因为如此，我目前会这样用它：
把 Config Studio V2 作为一个很强的分析和准备工具来用，但关键 edge cases 仍然要回到真实 firewall UI 和真实 traffic 上去验证。
结论
对我来说，Sophos Firewall Config Studio V2 属于那种乍看之下不算特别惊艳，但在真实日常运维中却非常有价值的工具。
它不是狭义上的 security feature。它不会直接挡住攻击，也不会修补漏洞。但它减少了很多错误最容易发生的那个位置上的 friction：理解和修改 firewall configurations。
而这在实践里非常值钱。
旧版 Viewer 已经有用了。到了 V2，它变成了一个在 audit、migration、rule cleanup 和较大 changes 上都更值得认真对待的工具。它不是唯一真相，但它绝对已经是围绕 Entities.xml 的一个非常好用的工作界面。
与此同时，这个工具的价值也再次说明：哪些能力本来就应该更靠近 firewall 和 Sophos Central。对我来说，最典型的例子就是检测被其他规则覆盖的 rules。这不是 bonus，而是你在构建和排序规则时就应该直接看到的帮助。
所以我真正的结论其实比这个单一工具更大：Config Studio 在我看来，像是在确认一件事——Sophos 在 firewall UI 和 Central 上已经太久依赖 workaround，而不是持续做真正的产品打磨。今天当然可以用 agentic development tools 很快做出一个外部 helper，但那不应该成为长期答案。workaround 再好看，也还是 workaround。
下次见，
Joe
