Sophos Firewall Config Studio V2: 単なる Viewer ではない
目次
2 月に Sophos は Configuration Viewer を公開しました。これは Sophos Firewall の世界にある大きな弱点のひとつ、つまり raw XML に苦しまずに configuration を読み、検索し、比較することを少し楽にしてくれた tool でした。その元の tool については、以前 Sophos Firewall Configuration Viewer を紹介した記事 で詳しく書いています。
2026 年 4 月 15 日、Sophos はさらに一歩進みました。これまでの Configuration Viewer は Config Studio V2 へと変わりました。この rename が重要なのは、単なる cosmetic change ではないからです。Sophos はもはやこれを viewer としてだけではなく、edit も担う browser-based tool として扱い始めています。
ここが面白いところです。読むだけなら一つの話です。しかし現実の firewall 運用では、理解すること、比較すること、そしてきれいに変更することの三つが同時に必要になります。
そして、まさにここから私の強い criticism も始まります。tool 自体は多くの点で良いのですが、Sophos がまたしてもこうした能力を actual firewall の外、そして Sophos Central や Firewall Manager の外で育てているという事実は見逃せません。部分的には、この side tool の方が firewall UI や central management より modern で powerful にすら見えます。admin の感覚としては、これはかなり引っかかります。
Sophos を長く見てきた人なら、この pattern に見覚えがあるはずです。目に見える UI 改善はとてもゆっくりです。widescreen monitor の扱いがまともになるまで、admin 目線ではあまりにも時間がかかりました。その一方で、古い UTM は今でも一部でより分かりやすい change logging を持っていて、誰が何を変えたかが見やすい場面があります。こうした quality-of-life の話は何年も後回しにされる一方、各 release では analyst や vendor の slide で映える機能が前に出がちです。
まず Sophos 自身の official overview を見たいなら、動画はこちらです。
Config Studio V2 とは何か
Sophos は Config Studio V2 を、firewall configuration を表示し、分析し、比較し、そして edit できる browser-based tool と説明しています。最初は新しい名前の新バージョンに見えるかもしれませんが、実際にはそれ以上です。
公式の方向性はかなり明確です。
- 単一の configuration を full report として読む
- 二つの configuration を比較する
- ゼロから新しい configuration を作る
- 既存の configuration を tool の中で直接変更する
- 結果を XML、TAR、API、
curloutput として再出力する
この時点で tool は「documentation を助ける utility」から「実際の作業 tool」へと変わります。同時に、Sophos が firewall や Central の中でまだ十分に解決できていない点もより見えやすくなります。
公式動画からも、Config Studio V2 が旧 viewer を大きく超えていることが分かります。そこではたとえば次のようなことが示されています。
- 完全に空の状態から新しい configuration を作る
- 既存の XML configuration を import して edit する
- firewall rules を作成し、順序を変更する
- shadowing を検出し、rule の移動や削除で解消する
- 多数の rule に対して logging を一括で有効化するような bulk changes
- object references の表示
- duplicate や unused object の検出
- CSV などからの bulk object import
- Microsoft JSON のような vendor data から cloud objects を生成する
- configuration を XML または TAR で再出力する
これは gimmick ではありません。実際の admin feature です。
日常運用でなぜ重要なのか
理論上、firewall changes は process、ticket、four-eyes principle、test plan に沿って行うものです。現実には、export、diff、古い二次系 firewall、あるいは引き継いだ environment を前にして、まず「ここには一体何が組まれているのか」を理解しなければならない場面がよくあります。
そこで Config Studio V2 が効いてきます。
Audit と review のために
他人が運用していた Sophos Firewall を引き継ぐとき、web UI はいつも最良のスタート地点とは限りません。NAT、firewall rules、objects、interfaces、VPNs、そして特殊ケースをクリックで追っているうちに流れを失い、最後には複数 tab に screenshot と note が散らばります。
整理された configuration report はずっと扱いやすいです。menu を行き来する代わりに、rules、policies、settings を一つの流れで見られます。audit や review では非常に助かります。
Change window のために
私にとっては compare 部分の方がさらに重要です。大きな変更では、何かが変わったことを知るだけでは足りません。何が追加され、何が削除され、何が変わったのかを明確に見たいのです。
WAN migration、NAT の組み替え、VPN の変更、長年積み上がった rule set の cleanup のような場面では、きちんとした diff が本当に時間を節約し、余計な変更を混ぜてしまう risk も減らします。
MSP、handover、migration のために
多くの firewall を管理する人や、environment を team 間で handover する人なら同じ問題を知っています。configuration はしばしば複数の場所に同時に存在します。
- firewall 本体
- ticket
- spreadsheet
- どこかの wiki
- そして最初に構築した人の頭の中
Config Studio V2 はこの gap を少し縮めてくれます。good documentation の代わりではありませんが、handover や review のためのはるかに良い starting point です。
旧 viewer と比べて何が変わったのか
元の Configuration Viewer は主に reading と diff の tool でした。それだけでも十分役に立ちました。Sophos の XML は人間の目に優しいものではないからです。
V2 で加わった決定的なステップは editing です。
Sophos は公式にこれを configuration editor と呼んでいます。つまり export を import して analyze するだけでなく、tool 内で変更し、再度 download し、必要なら API や curl output として利用できるようになったわけです。
この API と curl output が面白いのは、すべての admin が突然 full automation に進むからではありません。変更をより repeatable にし、document しやすくし、既存 workflow に取り込みやすくするからです。
これは、いきなり infrastructure as code platform を作らなくても、firewall changes をもう少し controlled かつ reproducible にしたい team にとって特に意味があります。
だからこそ、Viewer から Studio への rename は、私には「これを side で少しずつ大きくしている」という印象も与えます。ここに機能が増えるほど、「なぜ firewall や Sophos Central に直接入らないのか」という問いは強くなります。
実際の workflow はどう見えるか
良い点は、入り口が今もシンプルなことです。Config Studio V2 も exported configuration を前提に動きます。
1) Configuration を export する
Sophos は引き続き firewall configuration から Entities.xml を求めています。手順は次の通りです。
- WebAdmin の
Backup & firmware > Import exportに行く - full または selective configuration を export する
- download した
API-xxxxxx.tarを unpack する - 中にある
Entities.xmlを Config Studio に upload する
ここは重要です。community でもすぐ話題になった通り、直接の input は TAR そのものではなく、そこから取り出した Entities.xml です。
2) Report を読むか comparison を始める
その後の流れは大きく二つです。
- 単一 configuration を読んで analyze する
- 二つの configuration を compare する
多くの admin にとって、最初の使い方だけでも十分有用です。特に、ある object がどこで使われているか、どんな rule group が本当にあるか、特定 policy がどう組まれているかを知りたいときに役立ちます。
3) 新しくできるようになったこと: edit
V2 で新しく加わったのが editing です。configuration を修正し、再度 download し、必要なら XML、API、curl として再利用できます。
これによって Config Studio が firewall UI の replacement になるわけではありません。でも、その価値が明確に「change workbench」寄りになったのは確かです。
私が一番 value を感じる場面
Config Studio V2 がすぐ役立つ practical な use case は四つあると思います。
大きな change の準備
maintenance window の前に、どの rules、objects、NAT relationships が変わるのかを把握したいなら、整理された report と before/after diff は XML や UI 行ったり来たりよりずっと楽です。
既存 rule set の review
Sophos 環境の多くは長年かけて肥大化します。古い host object、duplicate service、historical NAT rule、project の残骸が残ります。こうしたものを読みやすくする tool は、新しい change だけでなく cleanup にも効きます。
他 team や provider への handover
configuration を review する全員が direct admin access を持つ必要はありません。整理された export や report の方が良い土台になることも多いです。
より reproducible な change への入口
API と curl output は、Sophos がこのテーマをどこへ持っていきたいかを示す最も分かりやすい signal です。単なる visibility ではなく、より structured な configuration work です。
これは、infrastructure as code に全面移行しなくても、変更の一部を standardize したい team にとって魅力的です。
SFOS に直接足りていないもの
ここが私の本当の criticism です。
Config Studio V2 が有用であればあるほど、こうした機能の多くは external である必要がない、と感じます。実際の admin ergonomics を考えるなら、私は次のようなものこそ SFOS の中に欲しいです。
- firewall rules の bulk editing
- 複数 rule の一括 enable、disable、move
- NAT rules の proper clone
- objects の bulk rename
- host、service、FQDN references の search and replace
- unused object の検出と cleanup
- duplicate の検出と merge
- rule 作成時の conflict の可視化
- rule block の clone や移動
- change commit 前の before/after comparison
- external tool を介さない bulk object import
大きな environment では、これだけで daily operations はかなり改善します。その代わり今も export、unpack、upload、そして戻すという workflow のままです。動くことは動きますが、elegant ではありません。
そしてここは intentionally critical に言います。動画を見ると、Sophos が firewall UI や Sophos Central を本気で modernize するよりも、使い勝手の良い機能を separate browser tool に載せる方を優先しているのがかなり明確です。私たちは今でも NAT rule のまともな clone function のような basic なものを待っています。一方で conflict detection、bulk editing、object analysis、cloud import は Studio に入っていきます。vendor 目線では実装も whitelist もしやすいのでしょう。でも admin 目線では、便利な機能が日々の作業場所とは別の parallel world に住みついてしまう構図です。
だから Config Studio は私にとって単なる新しい tool ではなく、confirmation でもあります。Sophos が firewall UI と Central に関して何年も行き詰まってきたことを示しているように見えます。low-hanging fruit はまだ転がっているのに、external tool が急にそれをうまく解決しているのです。
Import/export model がまだ完全には納得できない理由
小さな review にはこの model でも構いません。ですが本番の変更となると、admin 目線では少し awkward に感じます。
export された configuration に対して tool が動く時点で、いくつかの practical risk がすぐ出てきます。
- export した configuration がすでに古いかもしれない
- 複数 admin が parallel に作業していて export が追いついていないかもしれない
- sensitive な firewall data が laptop や project folder に file として残る
- analysis、edit、re-import の間に drift が生まれる
これは Config Studio V2 が悪いという意味ではありません。現時点の workflow が、最もきれいな native solution というより workaround 的に見える、というだけです。
audit や planning には合っています。でも daily administration には、私はやはりもっと firewall の中に欲しいです。
security の観点ではもう一点あります。Sophos は processing が browser 内で local に完結すると説明しています。これは良いことで、firewall configuration 全体を遠隔の cloud service に upload するよりは明らかにましです。それでも、これは conscious に受け入れるべき trust model です。扱うのは harmless な file ではありません。network segments、objects、rules、NAT relationships、VPN definitions、そして security-relevant な metadata が含まれることもあります。
曖昧さは「何かが Sophos に送られるのかどうか」だけではありません。browser context 全体です。sensitive data を web-delivered tool に読み込み、配信される application、本地処理、browser 自体、extensions、local cache、そして admin system 上での export file の扱いを信頼する必要があります。technically local に留まるとしても、これは firewall や central management に neatly integrated な機能とは別の trust surface、attack surface です。
だからこそ、SFOS や Sophos Central への deeper integration の方がずっと clean だと思います。便利さのためだけではなく、roles、approvals、auditability、sensitive configuration data の扱いを一箇所にまとめられるからです。
もう一点。動画でも、まだすべての configuration component が fully supported ではないことが分かります。tool 自身が import 時にそれを警告します。未対応部分は削除することも保持することもできますが、Studio 内では完全には見えません。初期段階の tool なら理解できますが、それでもこれは real admin surface の完全な replacement ではないことを示しています。
Tool がまだ抱えている限界
この tool はまだ perfect ではありません。現時点では以下の点が missing か、まだ完全に clean ではありません。
Linked NAT rules が Any に見えることがある
公式 feedback thread で Sophos は、linked NAT rules が source や destination に対して Any と表示されるケースがあると述べています。これは classic な display bug というより、exported XML から reliable に判断できないという制約です。
これは重要です。rule quality check や shadowing の分析が、その表示に依存して誤解を生む可能性があるからです。
Sophos Central の .backup file はまだ clean な input ではない
community からは、暗号化された Sophos Central backup の .backup file を将来的にサポートするのか、という質問も出ています。現時点では未対応です。Config Studio は Entities.xml を前提にしているため、暗号化された Central backup は直接利用できません。
MSP にとっては特に useful なポイントなので、今後に期待したいところです。
Edge case は今後も残る
release 直後の数日ですでに、特定の special case における差異の報告が出ています。若い tool なら不思議ではありませんが、だからこそ私は今の段階ではこう使います。
Config Studio V2 は強力な analysis と preparation の tool として使う。一方で critical な edge case は actual firewall UI と real traffic に照らして確認する。
結論
Sophos Firewall Config Studio V2 は、最初に見た印象よりも日常運用でずっと価値のある tool です。
狭い意味での security feature ではありません。attack を防ぐわけでも、vulnerability を patch するわけでもありません。しかし多くの mistakes が起きる場所、つまり firewall configuration を理解し変更する場面の friction を減らしてくれます。
それは実務では非常に大きい価値です。
旧 Viewer もすでに useful でした。V2 では audit、migration、rule cleanup、大きな change において、もっと真剣に radar に載せるべき tool になりました。唯一の真実ではありませんが、Entities.xml を扱う上で非常に有用な working surface です。
同時に、この tool の value は、Sophos が何を firewall や Sophos Central にもっと近づけるべきかも示しています。私にとって一番分かりやすい例は、rule が他の rule を覆ってしまう状態の検出です。これは bonus ではありません。rule を組み立て、並べ替えるときにこそ直接見たい支援です。
だから私の本当の結論は、このひとつの tool よりも大きいです。Config Studio は、Sophos が firewall UI と Central において real product care より workaround に頼りすぎてきたことの confirmation に見えます。today の agentic development tools なら、external helper を素早く作ることはもちろんできます。でもそれが long-term answer になってはいけません。workaround は polished でも workaround のままです。
また次回、
Joe
