Sophos Firewall v23：進歩、限界、残された課題

Sophos Firewall v23 を自宅ラボで約2週間テストしてきた。最初の印象は複雑だ。新しいルール表示は気に入っているし、REST API も良い方向だと思う。一方、管理画面には、異なる時期に開発された部分が並んでいる感覚が残る。新しい表が一つ加わっても、管理全体が現代的になるわけではない。

私が重視するのは新機能の数より、ルールを明確に管理できること、反復作業を自動化できること、画面を移るたびに別の操作方法を覚え直さずに済むことだ。v23 は前進しているが、基本的な要望もまだ残る。ここでは最初の使用感に加え、大きな変更を技術的に評価する。

Sophos Firewall v23 は現在 Early Access Program（EAP）の段階にある。過去の公開時期から、正式版は2026年12月になると予想している。ファームウェアを自宅ラボで約2週間試したが、本番環境では使用していない。操作性については私自身の観察であり、HA と WAF の性能値は Sophos によるものだ。

ルール管理：優れたフィルターだけでグループ表示をすべて代替できるわけではない

新しいルール表示は、ラボで気に入った変更の一つだ。連続した表、変更・固定できる列、検索とフィルターは有用だ。宛先、サービス、保護プロファイルを並べて比較できる方が、複数のルールを毎回開くより合理的だ。機器の識別情報と HA 状態が常に見えることも、作業の文脈を保つ助けになる。

ただし、グループ表示への批判は理解できる。初期のフィードバックでは、従来の折りたたみ可能なグループが新表示に再現されていない点が指摘された。ルールが多いと、フィルターがあっても長い表は把握しにくい。これは好みだけでなく、安全な管理に関わる。

Sophos のルール管理に関する説明によれば、既存グループとルール順序は維持され、所属グループは列に表示される。現在は両方の表示を選択できる。グループが削除されたわけではない。 表示方法が変わったのだ。議論されているタグによる整理は将来の可能性であり、現行ビルドで約束された機能ではない。

私は新表示が好きだが、大規模なルールセットを扱う管理者の事情も理解できる。数千のルールでは、フィルターや表示方法が実際の評価順序を明確に保つ必要がある。グループは全体の順序から独立したセキュリティ境界ではない。

約2週間使っても不満なのは、画面が統一されていないことだ。デザインや機能が場所によって異なる。複製操作も、どこでも同じ形で用意されているわけではない。レスポンシブな表示も部分ごとに差がある。設定画面を行き来すると特に目立つ。

似た作業には似た操作方法を期待する。ルール整理や類似設定の作成には、一貫した操作が必要だ。良い画面が一つできたことで、ほかの差がむしろ目立つ。Sophos には画面全体にまたがる改善を求めたい。

WebAdmin の HTTP/2 は歓迎するが、これらの問題を解決するものではない。特に遅延の大きい接続ではページのリソース転送に役立つ可能性がある。しかし操作ロジックは変わらず、設定変更時間が自動的に短縮されるわけでもない。ここでは条件をそろえた変更前後の測定は行っていない。

REST API：進歩を決めるのは検証可能な作業手順

REST API は v23 の有用な方向性の一つだと思う。繰り返す管理作業をすべてクリックで行う必要はない。API キー、OpenAPI 3.0、組み込みガイドは独自ツールの基盤になる。キー、有効期限、アクセスを許可する IP ホストは Administration > API access で管理する。

価値があるのは、現状を読み、差分を特定し、必要な変更を加え、保存結果を再読する管理可能な手順だ。複数拠点での反復作業を追跡しやすくする使い方が考えられる。ただし、私が実証した複数拠点展開ではない。

API があるだけで自動化が信頼できるとは限らない。到達不能の拠点は失敗として表示し、再試行で重複オブジェクトを作らず、部分的な失敗を記録する必要がある。私はそうした点で連携を評価する。

キーは管理された自動化ホストに置き、期限とネットワークアクセスを制限すべきだ。対話型ガイドは実際のリクエストを送れる。書き込み例は現実の設定変更なので、画面操作と同じように確認する。

機能の網羅性はまだ確認事項だ。既存の XML 自動化を置き換えるには、対象ビルドの OpenAPI 定義に必要な操作がすべて含まれている必要がある。Sophos は WAF の変更について引き続き XML API を明示している。方向は正しいが、実用性は対応範囲、エラー処理、権限で決まる。

WAF は便利になるが、容量には限界がある

Web Application Firewall に、サイトのパスエントリーごとのアクションが加わる。アプリケーション公開に有用で、SG/UTM9 との差も部分的に埋める。四つのアクションの安全上の意味は異なる。

リダイレクトはクライアントの宛先を変えるのであり、内部でバックエンドを切り替えるものではない。WebSocket の例外も保護の追加ではない。保護するポータルと WebSocket 経路を併用するなら、どこを検査するか意識して決める必要がある。接続できることは検査された証拠ではない。

一つのパスルーティングエントリーには最大128パスをまとめられる。WAF ルール上限は初期値100で、200まで増やせる。ガイドでは既存ルールを Protect を既定アクションとして移行するとしている。画面と XML API の対応は明示されているが、すべての WAF 手順が新 REST API に含まれるという意味ではない。

Apache Event MPM も変更点だ。Sophos は worker の利用効率と同時リクエストへの耐性改善を説明している。発表にある約800の並列リクエストは、旧アーキテクチャが飽和し得た状況の説明だ。旧版共通の固定上限でも、新版の保証スループットでもない。

パスごとのアクションは具体的な改善だ。性能の約束は分けて考えたい。キューが改善しても、アプリが実用にならないほど遅い可能性はある。接続数より応答時間、エラー率、バックエンド遅延が重要だ。私は同等負荷での WAF 比較測定をしていない。ルール上限が増えても機器の性能が比例して増えるわけではない。

WebAdmin の HTTP/2 を WAF のプロトコル対応と混同してはいけない。リンクした Reddit では WAF の HTTP/2 は将来の要望として扱われている。返信は関心を示すが、約束ではない。v23 の機能とも HTTP/3 の保証とも書けない。

HA：300ミリ秒はアプリの無停止を意味しない

HA の変更は特に気になる。Sophos はピアの障害検出時間を4秒から300ミリ秒に短縮し、約13倍速い検出としている。

この数値は障害検出を示す。 通話、VPN、アプリが300ミリ秒後に正常になる保証ではない。残ったノードの引き継ぎ、隣接機器の転送、既存セッションの扱いも影響する。ping 一つでは十分に把握できない。

監視には SSD などのハードウェアも含まれる。ノードが HA リンクに応答していても、ストレージに問題があることは考えられる。ハードウェア健全性を切り替え条件に使うのは合理的だ。健全なノードで運用を続けても、原因調査や部品交換は必要になる。

通常のデータトラフィックから分離した経路で HA ハートビートを優先することも重要だ。Sophos によれば負荷に応じて優先度を調整し、遅れを障害と誤認するリスクを減らす。ガイドが述べるのはハートビート欠落と意図しない切り替えの大幅削減であり、完全な免疫ではない。

設計としては妥当だ。高負荷で理由なく切り替わるクラスタでは、検出が速くても意味が薄い。本番の受け入れ試験では両方を見る必要がある。私のラボの印象は HA 中断時間の実測でも、本番負荷での安定性の証明でもない。

DNS とパッチ状態：異なる二つの信頼

DNS over HTTPS は選んだリゾルバーまでの通信を暗号化する。DNSSEC は署名済み DNS データの署名チェーンを検証する。補完関係にあるが、DoH 自体は応答の真正性を認証せず、DNSSEC は問い合わせを隠さない。リゾルバーは問い合わせを知り、すべてのゾーンが署名されているわけでもない。

Sophos は自社または一般プロバイダーへの DoH と、DNS Protection の簡単な有効化を説明している。全クライアントが自動的にその経路を使うわけではない。ブラウザー独自の DoH、内部リゾルバー、プライベート名前空間も設計が必要だ。内部・外部名を正しく解決し、フィルターと DNSSEC 検証判断を理解できることを求める。

ホットフィックス表示は派手ではないが実用的だ。Backup and Firmware に適用済みセキュリティ更新の CVE、説明、日付、重大度、アドバイザリーへのリンクが表示される。Log Viewer、メール通知、Central Firewall Reporting もガイドに記載されている。

ファームウェア番号だけではパッチ状態をすべて説明できない。ホットフィックスの記録は個別修正の適用確認に役立つが、全脆弱性の修正や過去に侵害されなかったことを証明しない。

Sophos Fusion の定期ファームウェア計画には段階的展開と機器別例外が加わり、メジャー版は任意で含められる。私はテストグループから始め、重要機能を確認して次に進む。自動化は手間を減らすが、復旧計画の代わりではない。

DHCP、mDNS、ルーティングには独自の受け入れ確認が必要

DHCP は新 Control Plane に移る。Sophos はリース処理、予約数、サービス前のフラッド対策、画面設定の改善を説明している。見た目だけの変更ではない。リース、更新、予約、特殊オプションを確認したい。Web ページが開くだけでは PXE やめったに再起動しない専用機器の設定を確認できない。

mDNS リフレクターは選んだ VLAN・サブネット間でサービスを検出し、IPv4 と IPv6 に対応する。インターフェースとサービスを選択できる。ただしその後のデータ通信が自動許可されるわけではない。プリンターが見えても、ルール不足で印刷できない場合がある。設定が簡単だからと、ゲストから内部機器をすべて見えるようにしてはいけない。許可されないことの確認も必要だ。

FRR の更新と統合コンソールもある。BGP と静的ルート向け BFD は単独構成での実験機能と明記されている。検出するのは転送経路の障害で、HA ハートビートとは異なる。現段階では本番の依存機能にしない。

IPv6 IPoE、IPIP/DS-Lite を含む4in6トンネル、VNE を理解する DDNS は、日本の Xpass を含む接続方式を拡張する。エンドポイントと MTU/MSS の改善は、その方式を要求するプロバイダーに有用であり、IPv6 全般を解決するものではない。IONOS Cloud では公式イメージの Bring Your Own Image を使い、Marketplace 掲載はなく、ライフサイクルは手動管理になる。

ID：更新しても前提条件は自動でそろわない

Entra ID の拡張は Sophos Endpoint と Synchronized User ID の連携であり、ポータル認証の改名ではない。ガイドはオンプレミス AD と Entra のハイブリッド環境、UPN と sAMAccountName のマッピング、記載された Endpoint 2025.1 からの Windows 対応を説明する。Entra だけで識別できるわけではない。バージョン、ライセンス、SSO 構成が必要だ。

Google Workspace は Captive Portal、VPN Portal、Sophos Connect、WebAdmin の OpenID Connect IdP として記載され、IdP 側の MFA を利用できる。対象サービス群ごとに一つの IdP という制約もある。認証と認可は別だ。有効な Google アカウントが意図せず管理権限を得てはいけない。

MFA 登録 QR コードはメールで送信でき、新規導入では既定となる。既存・移行環境はポータル方式を維持する。未使用コードは24時間で失効する。登録コードには認証アプリの秘密情報が含まれるため、メールボックスと再登録手順の保護が必要だ。メール送付だけで安全な本人確認になるわけではない。

共有サーバーでは SATC と XDR Sensor を既存 Endpoint・AV と併用し、同一 IP の複数セッションにユーザー別ルールを適用できる。導入前に OS、ライセンス、具体的な他社製品の組み合わせを確認する。

Chromebook 拡張は Manifest V3 ベースで、サポート中のすべての SFOS を対象とする。v23 専用の更新理由ではない。共有端末では、ログアウトやユーザー交代でマッピングが確実に終了するかが重要だ。

AI と NDR：判断は見える状態に保つ

Sophos Fusion の Firewall Assistant 第1段階はルールに重点を置き、設定の読み取りと質問への回答を行う。意図的な例外はルール作成で、無効状態で表の最後に追加される。確認と有効化は管理者が行う。ガイドでは、Fusion SSO を通してその管理者が見られるデータとアクセス範囲を一致させている。

この境界は良いと思う。下書きでもオブジェクト、サービス、ユーザー、保護プロファイル、位置を確認する必要がある。無効でも保存済み設定への変更である。説明の巧さは安全の証明ではない。

Generative AI カテゴリーとアプリケーションフィルターは、Sophos AI Defense の承認サービス制御を支える。ドメインを許可しても、プロンプトに入れてよいデータは決まらない。ネットワーク制御ではすべてのアップロードを完全に検査できず、データ分類も代替しない。追加サービス、ライセンス、能力は個別に評価すべきだ。

NDR Essentials と NDR Active Threat Intelligence には、自動隔離や赤い Heartbeat を伴わないアラートが加わる。可視化と即時遮断を分けるものだ。Active Threat Response のすべての動作が無効になる意味ではない。自動応答のないアラートには担当者とエスカレーション経路が必要だ。

小さな変更では、メール Content Control Lists の ID 参照と、バックエンドの Web カテゴリー定義のバージョン管理がある。更新・復元時の設定整合性に影響する点だ。

アップグレード前に移行する

最も厳しい変更は AI ではない。Sophos はネイティブ eDirectory サーバー種別を削除する。v23 認証文書は、先に対応種別へ移行し、旧設定を削除しなければ更新が失敗するとしている。

これは実際の移行案件だ。代替連携でログインできても、自動識別、グループ対応、ルールが正しい証拠にはならない。ディレクトリー SSO はマッピングを別に検証する。問題を切り分けるため、私は ID 移行を終えてからファームウェアを更新する。

EAP1 という段階も境界だ。サポートはコミュニティフォーラムで行われる。私にとっては復旧手順のある管理されたテスト向けであり、公開発表は重要インフラへの採用承認ではない。

初期フィードバックが示すもの

EAP1 のフィードバックには、ルール表示の批判に加え VMware の報告がある。22.0.1 から更新後、ping と SSH は通るが、30分後も WebAdmin に入れなかったという。検索索引に収録された続報で、同じ利用者は約40分後に復旧したと述べた。

単独の報告であり、私は原因を再現していない。一般的な VMware の欠陥や正常な所要時間とは扱えない。管理アクセス、更新時間枠、復旧を考える材料にはなる。初期議論は変化が速く、続報や反例も重要だ。

Reddit のリリース議論の WAF 問題も、運用者が気にする不足を示している。背景情報であり、ベンチマークや確認済み欠陥の完全一覧ではない。

約2週間後の最初の評価

v23 の方向は好きだが、全体はまだ統一されていない。新ルール表示は前進で、REST API は管理可能な自動化に向けた正しい方向だ。デザイン、機能、レスポンシブ表示には、現代的な管理体験に届かない差が残る。

HA、WAF、パッチの透明性は、AI の看板より技術的に重要だ。発表された改善には注目するが、初期テストは負荷比較や本番クラスタの経験を代替しない。メーカー値と各環境の受け入れ確認が引き続き必要になる。

ラボでは引き続き試す。本番導入は私にはまだ早い。正式版までに、新ルール表示がほかの画面の基準になることを期待する。操作の統一、異なる画面サイズでの使いやすさ、類似作業の差の削減は、独立した新機能をもう一つ増やすより役に立つ。

また次回。
Joe

よくある質問