Sophos Firewall Configuration Viewer: 設定の監査と比較

Sophos Firewall Configuration Viewer: 設定の監査と比較

3 min read
Network Sophos

皆さん、こんにちは

実運用でSophos Firewallを管理したことがあるなら、このジレンマはすぐに分かるはずです。設定はまさに「single source of truth」。でも、web UIの外で落ち着いてレビューしたい、ちゃんとドキュメント化したい、あるいは変更前/変更後を比較したいと思った瞬間に、一気に面倒になります。

もちろんスクリーンショットは撮れます。個別にルールをエクスポートすることもできます。でも、少し大きめの変更(WAN移行、新しいVLAN、オブジェクトの整理、NATロジックの組み替え、「ちょっとだけ」VPNを調整)になった途端、欲しくなるのはこの2つです。

  1. 読める設定。
  2. 「XMLをdiffして泣く」ではない比較。

そこで出てくるのが Sophos Firewall Configuration Viewer です。

このツールは責任を肩代わりしてくれるわけではありません。設定をきれいに設計し、変更を正しくテストするのは引き続きあなたの仕事です。でも、日常業務でとてつもなく時間を食うものを一つ確実に減らしてくれます。フォーマット問題です。技術的には正しいけれど読みづらいエクスポートを、実際に作業できるビューに変換してくれます。

そして私はこういうところがかなり細かいです。Changeを計画するときに知りたいのは「変わった」ではなく「何が、どれだけ、どこで変わったか」。ついでにオブジェクトやNATルール、VPN設定を横で触ってしまっていないか。Viewerはその確認にすごく現実的な助けになります。

Sophos Firewall Configuration Viewerとは?

Sophos Firewall Configuration Viewerは、Sophos Firewallの設定を 人間が読める形式 に変換するブラウザベースのツールです。主に次のことができます。

  • 設定のフィルタ、並べ替え、検索
  • 特定のオブジェクト/ホスト/FQDNを検索し、どこで参照されているか確認
  • 2つの設定を比較(Added/Modified/Removed)
  • 結果を HTMLレポート としてエクスポート

重要なのは、これはブラウザで開くだけの スタンドアロンツール だという点です。インストール不要で、基本的にどの管理用ノートPCからでも使えます。既存の運用フローにスッと入りやすいのが魅力です。

内部的にはSophosが提供する設定エクスポート(通常はXML、Entities.xml)を利用します。違いは「見せ方」です。XMLを眺めるのではなく、整理されたドキュメントのようなビューになります。

そして単なる「表示」ではありません。実際によく使うのはこの3つです。

  1. 読む:構造化されたビューで、フィルタ可能。
  2. 検索/参照:オブジェクトを探し、どこで使われているかを見る。
  3. 比較:変更前/変更後、またはFirewall AとFirewall Bの比較。

セキュリティとプライバシー面で重要な点として、Sophosは「データは ブラウザ内でローカル処理 され、外部に送信・保存されない」ことを強調しています。解析やレポート生成も手元のデバイス上で完結する想定です。

ツールはこちらです: Sophos Firewall Configuration Viewer

まずは短いウォークスルーを見たい場合は、SophosのTechVidが分かりやすいです。

SMBの現場でよくある話

金曜の15:30。従業員80人規模の会社で、インターネット回線が切り替わり、パブリックIPも変更。並行して小さなプロジェクト(CRM導入、サブネット追加)も走っています。Change requestはきちんと書かれていて、どのNATルールを変えるか、どのVPN endpointを直すか、どのFirewallルールが対象かも明確です。

でも現実はだいたいこうなります。

  • WAN_Public_IPs のようなオブジェクトが、NATルール3本、business application rule 2本、そして何年も誰も見ていない「歴史的」なWAFルールにもぶら下がっていた。
  • SaaSのFQDNオブジェクトがいつの間にかグループに入っていて、10本のルールに登場しているが、実際に必要なのは2本だけ。
  • 片付けたい。でも月曜朝に「ChangeしてからXが動かない」と電話が来るのは避けたい。

ここでConfiguration Viewerが本当に効きます。

私がよくやる流れはこうです。

  1. 変更前にエクスポート(baselineを保存)
  2. Changeを実施
  3. 変更後にエクスポート
  4. Viewerで diff を取り、HTMLをチケットに添付
  5. オブジェクトを削除する前に Usage Reference で参照先を確認

単なる便利機能ではなく、変更の追跡性が上がります。監査、社内承認、そして未来の自分にとって、これが重要です。

実際の使い方

1) 設定をエクスポート(Full / Selective)

Firewallから直接エクスポートします。

  • WebAdmin: Backup & Firmware > Import / Export
  • Export full configuration(全体)か Export selective configuration(一部、必要なら “Include dependent entity”)

Sophosは設定を .tar として生成し、ダウンロードできます。

運用上、ここは差が出ます。

  • Full export:change management(baseline/diff)の基本。依存関係を落としにくい。
  • Selective export:特定領域だけレビューしたいとき(例:interfaces + routingのみ)、または第三者(ISP/vendor)に渡すときに情報を絞りたいときに便利。
  • Include dependent entity:Selective exportでは重要になりがち。Firewall rulesを出すなら、参照しているnetwork/service objectsも一緒に欲しい。そうしないとコンテキストが欠けます。

比較のPro tip: “Compare” を使うなら、必ず 同じ選択内容で2つの設定をエクスポート してください(Full vs Full、またはSelective vs Selectiveで同一チェック)。FullとSelectiveを比較すると差分が派手になりますが、運用上はほぼ役に立ちません。

2) TARを展開して Entities.xml を見つける

.tar から Entities.xml を取り出します(環境によっては entities.xml の場合もあります)。

macOS/Linux:

tar -xvf backup.tar
ls -la

Windowsなら7-Zipなどで展開できます。

私のおすすめは、Downloadsに放置しないこと。macOS/Linuxなら一時ディレクトリで作業できます。

WORKDIR="$(mktemp -d)"
tar -xvf backup.tar -C "$WORKDIR"
ls -la "$WORKDIR"

最後にディレクトリを削除すればOK。地味ですが、こういう衛生管理が「機密設定が何週間もPCに残る」事故を減らします。

セキュリティ観点では、Sophosのドキュメントによると、機密情報を含まないエクスポート(例:interfacesだけ)では Entities.xml のみのことが多いです。一方、機密情報(例:users)を含む場合、TARに hashFile.jsonpropertyfile といった追加ファイルが含まれることがあります。

つまり:TAR全体を機密として扱うべきです。

3) 設定を「読める形」にする

Viewerで “Single configuration”(または類似)を選び、Entities.xml をアップロードします。すると読みやすい形で表示されます。

設定サイズによっては数秒かかります。その後は、web UIでよくある「コンテキストが分断される」問題がかなり解消されます。

左側のフィルタが特に便利です。routing/NATのChangeなら、report設定やログ設定などを延々とスクロールしたくありません。必要なセクションだけを 有効にできます。

よく使うフィルタ例:

  • firewall rules + NATのみ
  • interfaces + routingのみ
  • VPNのみ

環境を初めて監査/引き継ぐとき、私はだいたいこの順で見ます。

  1. interfaces/zones(内側/外側の整理)
  2. routing/SD-WAN(出口、戻り経路の理解)
  3. NAT(公開と書き換えの把握)
  4. firewall rules(許可フローの確認)
  5. VPN(site-to-site / remote access)

唯一の正解ではありませんが、トポロジーを理解しないままルールを評価するのを防げます。

必要ならいつでも HTMLレポート をエクスポートできます。

私はこれを「レビュー用パッケージ」として使います。HTMLを出してチケットに添付(あるいは内部の安全なドキュメント領域に保存)すれば、別の人がFirewallへのアクセスなしでレビューできます。四眼レビュー、社内承認、外部監査に強いです。

4) Usage Reference: 「このオブジェクトはどこで使われている?」

私にとってはこれがキラーフィーチャーです。

Sophosの設定は objects(hosts、networks、services、FQDNs、groups)に強く依存します。再利用できるのは良いのですが、数年運用すると「このオブジェクト、どこで使ってる?」が分からなくなりがちです。

そして典型的な事故が起きます。

  • 「古そうだから」とオブジェクトを消して、後からNATルールで使っていたことが判明する
  • オブジェクト(例:IPレンジ)を変更して、意図せず複数のポリシーが変わってしまう

Usage Referenceで依存関係が見えるようになります。 web UIで勘で探すのではなく、検索/Usage Referenceで「どこで参照されているか」を確認できます。

TechVidの例だと、box を検索すると、FQDNオブジェクトがどのpolicy/NATルールで使われているかがすぐに分かります。

クリックで追えるのも良い点です。検索からオブジェクトに飛び、参照先(どのFirewall policy、どのNAT ruleが使っているか)を確認できます。私はcleanup changeのとき、この画面をHTMLにしてチケットに添付することが多いです。後から「なぜ消した/変えた」が説明できます。

用途:

  • cleanup(古いオブジェクトの削除)
  • change planning(どのルールを本当に触るべきか)
  • troubleshooting(なぜルールがまだマッチするのか)

5) 2つの設定を比較(Before/After)

トップページで “View” の代わりに “Compare” を選び、2つの Entities.xml をアップロードします。

シンプルですが強力です。私は例えばこういう用途で使います。

  • changeのbefore/after(定番)
  • test/stagingとproductionの差分(driftの検出)
  • 移行後の検証(新WAN、新NATロジック、新VPN)

Compareの良いところは、単なるテキストdiffではないこと。変更を意味のある形でまとめて見せようとします。「XMLが違う」ではなく「このオブジェクトが追加」「このルールが変更」「このエントリが削除」といった形になります。

change managementに必要な情報が揃います。

  • summary(removed/modified/added)
  • object/ruleごとの詳細
  • raw XMLの左右表示(任意)
  • ticket/audit向けHTML export

私の流れはかなり単純(でも効く)です。

  1. まずsummaryを読む:規模感が想定通りか?(例:3ルール変更のはずが200 objects modifiedなど)
  2. 重要領域に絞って見る:interfaces/WAN、routing、NAT、VPN、firewall rules
  3. 記憶が新しいうちにHTML exportを保存する

特に1が精神衛生に効きます。想定したものだけが変わっていると分かった時点で、週末の睡眠が変わります。

大きなChangeほど、before/afterのdiffを残す習慣は強いです。

機能をもう少し深掘り

ここまででも十分使えますが、何度か使うと「viewerは小さな運用ツールボックスだ」と分かります。私がよく使う機能をもう少し詳しく書きます。

Human-Readable View: UIのクリックマラソンを終わらせる

Sophosのweb UIは論理的に整理されていますが、ページに散らばっていて監査やchange planningではコンテキストが切れます。

Viewerはこれをコンパクトにまとめます。私は次の確認に使います。

  • interfaces/zonesは本当にどうなっている?
  • NATで何が公開されている?
  • 「昔は必要だった」広すぎるルールはどれ?

クリーンな設計の代わりにはなりませんが、最終的に どう記述されているか が見えます。

Filters: 今見るべきところだけを見る

左のフィルタは地味ですが強力です。多くのChangeは全体ではなく一部(WAN、NAT、VPN、routing)に集中します。

例えば回線切り替えなら、私は以下に絞ります。

  • interfaces/WAN
  • routing/SD-WAN
  • NAT
  • firewall rules(影響するフロー)

これでレビュー時の「脱線」が減ります。

Search: 「box」から「10.20.30.0/24」まで

運用から入ると、手元にあるのは症状だけだったりします。

  • “box.comへの通信が通らない”
  • “支店ネットワーク10.20.30.0/24がアクセスできない”
  • “そもそもSMTPが開いている理由は?”

名前、IP、FQDN、オブジェクトで検索し、関連箇所へ素早く到達できます。

Usage Reference: 痛い目を見る前に影響範囲を把握する

Usage Referenceは、cleanupが「勇気」なのか「無謀」なのかを分けます。私は主にこの3ケースで使います。

  1. オブジェクト削除:参照がゼロか確認してから。
  2. オブジェクト変更:間接的に影響するルール数を確認してから。
  3. Change計画:同じオブジェクトに依存するルールを把握してから。

これを徹底すると「え、ここにもぶら下がってたの?」が激減します。

Compare + HTML export: change managementの標準フロー

Compareは私の「変更が意図通りだった証拠」です。

だいたいこうします。

  1. before export
  2. after export
  3. Compare
  4. HTML diffを保存し、チケットに添付

少し几帳面に見えますが、数分で済み、後で「何が変わったの?」に答える時間を大きく減らします。チームレビューにも便利です。

セキュリティ:良い点と限界

1) privacy-firstは素晴らしい。ただし油断は禁物

「ブラウザから外に出ない」という設計は大きなメリットです。

ただし、Firewall設定はほぼ確実に機微情報です。パスワードが平文でなくても、以下が含まれがちです。

  • 内部ネットワーク、VLAN、IP体系
  • NAT定義と公開エンドポイント
  • VPNトポロジー
  • オブジェクトグループ(想像以上に情報が漏れる)

2) 本当のリスクは export の取り扱い

Viewer自体は読むためのツール。でもリスクは前後にあります。

  • TARのダウンロード
  • 展開
  • HTMLレポートの保存/共有

Sophosは、機微情報を含むexportでは追加ファイルが含まれる場合があることや、import時にsecure storage master keyが重要になることをドキュメントで触れています。

日常的なアドバイス:

  • exportファイルをローカルに長く置かない(作業後に片付ける)
  • “オープン"なチケットシステムにレポートを放り込まない
  • 第三者と作業するなら selective export を優先し、必要最小限だけ共有

3) SSH/Advanced Shell: exportに入らないものは見えない

現場では、障害時にSSHで入りAdvanced Shellで「とりあえず直す」ことが起きます。

重要なのは、その修正がreboot後に残るかどうかではなく、export(Entities.xml)に入らないものはviewerでは見えないという点です。Advanced Shell/SSHの調整は、必ずしも「通常の設定」としてexportに反映されないことがあります。

SSH/Advanced Shellで触ったなら、別途ドキュメント化し、WebAdmin上の正式な設定として落とし込む計画を立てるのが安全です。そうしないとrestore、HA failover、firmware updateのタイミングで刺さるか、diffから漏れます。

4) 運用で効くルール

  1. 変な拡張が入っていないブラウザプロファイルを使う。
  2. TAR/HTMLは他の機密設定と同じ場所で管理する。
  3. 共有が必要なら selective export、そして依存関係を意識する。

まとめ

Sophos Firewall Configuration Viewerは派手な機能ではありません。でも正直、こういうツールが日々の運用を支えます。

私が見てきた多くの設定で、しんどいのは技術そのものではなく「追跡性」です。何がいつ変わった? このオブジェクトは本当に未使用? 変更のついでに他も触っていない? web UIで探せるものは多いけれど速くない。そしてXMLを直に読むのは誰も長くやりません。

Viewerはそのギャップを埋めてくれます。設定を落ち着いて読めて、フィルタできて、参照関係を確認できて、最後にHTML diffを残せる。チームではレビューが楽になり、監査も穏やかになり、月曜の驚きが減ります。

一つだけ持ち帰るなら、反射を作ってください。

大きめのChangeの前にexport、Change後にもう一度export、CompareしてHTML diffを保存。 数分ですが「たぶんXだけ変えた」の事故を減らす最も確実な方法の一つです。

そしていつも通り、viewerは設定を 読みやすく するだけで、勝手に 安全 にしてくれるわけではありません。考えるのはあなた。viewerはそのための邪魔をしないツールです。

もし過去にSSHでAdvanced Shellへ入り「quick & dirty」にいじったことがあるなら、それがバックアップに出ない場合があること、つまりviewerにも出ないことは覚えておいてください。

参考リンク

では、また次回、 ジョー

© 2026 trueNetLab