Sophos Firewall v22 MR2：アップデートか、新たなリスクか？

Sophos Firewall v22 MR2が公開されました。Build 546は2026年7月14日にリリースされ、セキュリティ機能、認証動作、証明書対応の変更に加え、50件を超える修正を含みます。範囲は大きくありませんが、内容は有用です。

書面上は典型的なメンテナンスリリースです。しかし実際には、最近のSophosアップデートで私が慎重になる要素が揃っています。IPSの新しい検出ロジック、ユーザー割り当て動作の変更、新しい証明書チェーン、そしてkernel crash、HA障害、failsafe状態、VPN不具合、reporting停止の長い修正一覧です。

これは単純に良い知らせとは言えません。50件以上の修正はSophosが問題を整理している証拠である一方、GAとMR1に重大な問題がどれほど残っていたかも示します。このfirmware品質については、すでにSophos Firewall：CVEはなくてもバグはある（v21.5～v22）で批判しました。

私はMR2をすぐに自分のSophos Firewallの1台へインストールします。初日から無条件に信頼するためではありません。Build 546がv22系をようやく安定させるのか、それとも修正数以上の新しいバグを生むのかを確認するためです。特にHA、logging、IPsec、WebAdminの応答速度、STAS、pattern update後の安定性を調べます。

同時に、Sophosは奇妙な対比を作っています。公式firewall updateではConfig Studio 2.6が大きく扱われています。外部browser toolにはtemplate merge、改善された検索、multi-file diff、migration analysis、hardware compatibility dataが追加されます。一方、日常的に使うfirewall本体の画面には、目に見える改善がほぼありません。

そのため、MR2は技術的に重要でも、戦略面では残念なreleaseだと考えています。security engineに機能が増える一方、現代的な管理workflowは再びConfig Studioへ追い出されています。

重要ポイント

SFOS 22.0 MR2はBuild 546で、MR1 Build 490の後継です。Sophosが挙げる中心領域は7つです。

• post-quantum cryptographyの検出と制御
• 生成AI applicationの分類改善
• Manifest V3対応の新しいChromebook User ID extension
• STASの既定動作変更
• SFOS 23.0におけるNovell eDirectoryサポート終了の事前告知
• 新しいLet’s Encrypt trust chainとemail通知の改善
• analysis、migration、comparison機能を拡張したConfig Studio 2.6

さらに50件以上の問題が修正されます。運用面では、新機能より重要な修正もあります。kernel crash、HA障害、failsafe状態、VPN不具合、reporting性能問題が含まれるためです。

私の短い評価は次のとおりです。

• v22 GAまたはMR1を使用中で、記載された不具合の影響を受けているなら、MR2へ更新する明確な理由があります。
• 安定した21.5環境なら、PQCやConfig Studioだけを理由に急いで更新すべきではありません。
• PQC signatureはまず監視modeで運用し、直ちにDropへ設定しないでください。
• STAS環境では、upgrade後にIdentity Probe中の未認証trafficがどう処理されるか確認が必要です。
• HA、IPsec、WAF、mail、reporting環境では、緑色のstatusを見るだけでなく、実際の機能testが必要です。
• Config Studio 2.6は有用ですが、SFOS WebAdminが現代化した証拠ではありません。むしろ逆です。

hardwareの境界も重要です。SFOS 22.0はXGおよびSG hardware applianceをサポートしません。MR2の対象はXGS、virtual、software、対応cloud環境です。XG hardwareを運用中なら、MR2を通常の次期firmwareとして計画できません。

Post-Quantum Cryptographyの検出と制御

技術的に最も興味深い新機能は、post-quantum cryptography、略してPQCの制御です。Sophos Firewallが突然quantum computerを防御するという意味ではありません。将来の強力なquantum computerによる攻撃への耐性を意図した、現代的なkey exchange方式を扱います。

MR2はML-KEMに焦点を当てます。ML-KEMは2024年にFIPS 203として標準化され、Module Learning With Errors問題の困難性を安全性の根拠とします。NISTは3つのparameter setを定義しています。

• ML-KEM-512：keyとdata量が最小
• ML-KEM-768：中間で、現在特に広く採用されるvariant
• ML-KEM-1024：security levelは高いが、計算量と転送量も増加

SophosのMR2資料は、ML-KEMに基づくpureおよびhybrid key-exchange algorithmとのみ記載しています。対象parameter set、TLS group、signature IDは公開されていません。そのため、すべてのML-KEM variantを検出できると決めつけるべきではありません。

KEMが技術的に行うこと

ML-KEMはdata stream全体を直接暗号化しません。Key Encapsulation Mechanismは、単純化すると3つのoperationで構成されます。

1. KeyGenがencapsulation keyと対応するdecapsulation keyを生成します。
2. Encapsが公開encapsulation keyからciphertext objectとshared secretを生成します。
3. Decapsが相手側で秘密decapsulation keyを使い、同じsecretを復元します。

protocolはこのshared secretからsymmetric session keyを導出します。実dataは引き続きAESやChaCha20など高速なsymmetric algorithmで保護されます。ML-KEMが置き換えるのは危険性のある非対称key negotiation部分であり、TLS data encryption全体ではありません。

実際の背景はHarvest now, decrypt laterです。攻撃者は現在の暗号化trafficを保存し、数年後にcryptographically relevantなquantum computerで解読しようとします。短命なdataでは影響が小さくても、医療data、政府通信、知的財産、長期間機密であるべき企業情報では、必要な保護期間が新しい攻撃手段の実現までの時間を超える可能性があります。

Pureとhybridは同じではない

pure PQC key exchangeでは、negotiationのsecurityは新しいpost-quantum方式だけに依存します。hybrid方式はclassic mechanismとML-KEMを組み合わせます。実際のTLS実装で普及しつつある例がX25519MLKEM768で、classicなX25519とML-KEM-768の両方が最終secretへ寄与します。

移行期には合理的です。ML-KEMに実装不備や数学的弱点が見つかってもclassic componentが残ります。十分強力なquantum computerがclassic elliptic curveを破ってもML-KEM側が残ります。hybridは不要な二重暗号化ではなく、移行の橋です。

ただし、X25519MLKEM768は現行TLSの実例であって、Sophosがこのgroupだけ、または主にこれを検出するという主張ではありません。MR2資料はそこまで明記していません。

IPSが行うこと

Intrusion Prevention Systemには、pureおよびhybrid ML-KEM key exchangeを検出する新しいsignatureが追加されます。管理者は独自IPS ruleを作り、Allow、Drop、Resetなどを指定できます。

firewallはTLS handshakeで提示・選択されたkey exchangeを技術的に認識できます。clientがClientHelloでsupported groupとkey shareを提示し、serverがServerHelloで選択を確定するためです。暗号化application streamの開始前なので、その後のHTTPS contentを読まずに検出できます。

しかしSophosは、SnortまたはSFOS IPS pipelineのどの地点で判定するか、対象TLS version、proxy・DPI・非復号FastPath trafficの差を説明していません。release noteは機能を確認するだけで、内部data path実装を説明しません。production policyにはfirewall logとIPS logを用いた独自testが必要です。

actionごとの影響は異なります。

• Allowは接続を通し、loggingと組み合わせれば利用状況の把握に適します。
• Dropは一致packetを黙って破棄するため、clientは通常timeoutまたはhandshake失敗を確認します。
• ResetはTCP接続を能動的に終了します。失敗は早く見えますが、clientやapplication logでの見え方がsilent dropと異なります。

新signatureが既定で無効なのは正しい判断です。PQCは研究室だけの技術ではなく、大手browser、cloud service、web platformがhybrid方式をすでに試験または採用しています。一律にblockすれば正規のsiteやapplicationが停止する恐れがあります。

したがって導入手順は次のようにします。

1. signatureを有効化し、trafficを許可したまま記録します。
2. 数日から数週間、どのapplicationとdestinationがML-KEMを使うか分析します。
3. 社内cryptography policyが特定方式を禁止または要求するか確認します。
4. その後にのみ、必要な範囲へDropまたはResetを適用します。

最初のcommunity discussionでは、upgrade直後にPQC、KEM、quantumで検索してもsignatureが見つからないという報告がありました。pattern updateが未到着か、命名が異なる可能性があります。公開数時間後の情報だけで製品不具合とは断定できませんが、documentationの問題は示しています。signature名、SID、category、log fieldを見つけられなければ機能を管理できません。

policy変更前に、具体的に次を確認します。

• IPSは有効でNetwork Protection subscriptionは有効か
• install済みIPS pattern versionは何か
• 新signatureはどの名前とSIDで表示されるか
• 検出結果はIPS logとcentral reportingに現れるか
• DPI exception、TLS Inspection、FastPathでも同じように検出するか
• どのbrowser、OS、cloud service、社内applicationが検出されるか

Web Protectionが行うこと

Sophosによると、Web Protectionはweb sessionが未対応PQC algorithmをnegotiationすることも防ぎます。IPS signatureとは別の役割です。IPSはpatternを検出してactionを実行します。Web Protectionは管理対象TLS/Web workflowへ介入し、firewallが処理できない、またはpolicyが許可しない方式の利用を防ぎます。

特にTLS Inspectionで重要です。firewallはclientのTLS sessionを終端し、destination serverへの2本目のTLS sessionを構築します。2つのhandshakeと2組のsession keyが存在します。browserとweb serverがPQC対応でも、中間のinspection componentが提示groupを正しく処理できない場合があります。

制御がなければ、clientが新groupを提示してfirewallが仲介できない、serverが予期しないvariantを選ぶ、fallbackが想定外に動くといった原因の分かりにくいerrorになります。MR2は未対応PQC algorithmのnegotiationを防ぐものです。

一方、SophosはWeb Protection用のPQC policy matrix、対応group一覧、未対応offerを削除・拒否・classic fallbackのどれで処理するかを示していません。設定可能なIPS actionと同一視すべきではありません。

この機能は有用でも、cryptography strategyの代わりにはなりません。どのTLS接続を復号し、どこにexceptionがあり、PQCを監視するのか強制するのかは引き続き組織が把握する必要があります。

生成AI applicationの可視性を改善

2つ目のsecurity機能は、Synchronized Application Controlによる生成AI application分類の改善です。

仕組み自体は以前からあります。Sophos Endpointがどのlocal processが接続したかを把握し、Security Heartbeat経由でapplication contextをfirewallへ伝えます。port、destination IP、暗号化trafficだけでは識別できないsessionも、SFOSがprogramへ関連付けられます。

data pathを単純化すると次のようになります。

1. 保護されたendpoint上のapplicationがnetwork接続を開始します。
2. Sophos Endpointはprocess名、path、local application contextを把握しています。
3. Security Heartbeatがendpointとfirewallの情報を結びます。
4. SFOSが不明または粗くしか識別できないsessionをapplicationへ割り当てます。
5. applicationがSynchronized Application Controlに現れ、分類可能になります。
6. Application Filter Policyがtrafficを許可、block、shapeします。

Connection ListのResolve application infoは、未識別connectionについてendpointへ情報を要求できます。一覧は名前、path、category、endpointで検索できます。Sophosは管理上限を15,000 applicationとし、memory節約のためapplicationとendpointごとに直近5回だけ保持します。

MR2は生成AI applicationの割り当てを特に改善します。Sophos Endpointがより正確に識別し、SFOSへ情報を渡します。Generative AI categoryをApplication Filterやreportで利用できます。

管理者にとって重要な点は3つです。

• 可視性： 組織で利用中の生成AI applicationをreportで明確化
• rule： 認識したapplicationをより個別に許可、制限、block
• inventory： 承認済みと未承認AI serviceを区別する基礎

ただし「生成AIを検出」という表現を過大評価してはいけません。Synchronized Application Controlが主に答えるのは、どのapplicationが接続を作ったかです。次の内容は自動的には分かりません。

• 入力したprompt
• uploadしたfile
• 個人情報や機密情報が含まれたか
• browser sessionが私用か業務用か
• 許可済みservice内の組み込みAI機能を使ったか

固有process pathを持つdesktop clientは、同じbrowser process内の10個のAI web serviceより識別しやすいものです。URL categorization、TLS Inspection、cloud-app detectionは追加情報を提供できますが、技術的には別の検出層です。

価値はSophos Endpoint、activeなSecurity Heartbeat、有効なSynchronized Application Controlにも依存します。最初の有効化はSophos Centralから行います。SFOSのみ、またはHeartbeat経路外のendpointでは同じ深さを得られません。

正しい期待値はapplication attributionとpolicy基盤の改善です。許可するAI serviceや処理可能dataを決める組織的課題を単独で解決するものではありません。

upgrade直後にGenerative AI category全体をblockすべきではありません。まずendpoint context、firewall signature、web categorizationのどれによる検出かreportで確認します。実際の利用を理解せずMicrosoft 365、開発tool、browser、support platformの正規機能を止める恐れがあります。

認証とユーザー割り当ての変更

MR2には独立した3つの認証topicがあります。2つは具体的準備が必要で、残る1つは早期migration warningです。

Manifest V3対応Chromebook User ID

Sophos Chromebook User ID ExtensionがChromeの現行extension platformであるManifest V3へ移行しました。

重要なのは、旧extensionをuninstallし、新versionをinstallする必要がある点です。旧版のsilent updateだけでは足りません。集中管理Chromebookを持つ学校や企業はGoogle Admin policyで切替を準備し、test groupで確認してから全体へ展開すべきです。

extensionはSSO経路の一部にすぎません。Sophosは次の要件も示しています。

• firewall上のAD、LDAP、またはGoogle Secure LDAP server
• SFOS保護network内のChromebook
• 登録Google Workspace domainのuser address
• 暗号化通信用certificateと一致するCN
• 既定のSophos通信port 65123
• SFOSからexportしGoogle Workspaceへ登録するJSON設定
• accounts.google.com、Google API host、Chrome Web Storeへのaccess

Google WorkspaceではDevices > Chrome > Apps and extensions > Users and browsersから配布します。productionではForce installが適切です。必要なextensionをuserが削除できなくなります。またSophos User ID AppをAPI ControlsでtrustedにしなければOAuthが失敗する可能性があります。

切替後はinstall済みという表示だけでなく、経路全体を確認します。

1. userがChromebookへsign inする。
2. extensionが想定networkとcertificateでfirewallへ到達する。
3. userがLive usersへ表示される。
4. user-based ruleが実際にuserまたはgroupへmatchする。
5. sign outまたはdevice変更後に割り当てが正しく消える。

新extensionがなければ将来のupdateが止まる可能性があります。認証設計によってはuser mappingとuser-based firewall/web ruleが影響を受けます。学校ではfirewall、internet、Chromebookのすべてが「online」でもfilterが機能しない事態になり得ます。

STASはIdentity Probe中に既定でblockしない

Sophos Transparent Authentication Suiteでは、MR2からRestrict client traffic during identity probeの既定値がNoになります。

STASはWindows domain controllerで検出したuserをIP addressへ割り当てます。

1. userがWindows domainへlog onする。
2. domain controllerがSecurity Audit Eventを記録し、新しいWindowsでは通常Event ID 4768となる。
3. STAS AgentがeventからusernameとIP addressを読む。
4. agentが既定でTCP 5566を使いcollectorへ送る。
5. collectorが成功したmappingをUDP 6060でfirewallへ通知する。
6. SFOSが未知IPのtrafficを見た場合、port 6677でcollectorへ問い合わせる。
7. firewallが設定AD serverからgroup membershipを追加し、user-based ruleを適用する。

firewallが未割り当てIPを見つけるとLearning Modeに入ります。従来はprobe中のtrafficを既定で保留または破棄しました。documented defaultは120秒です。collectorが応答しなければ、そのIPは1時間未認証となり、未認証traffic用ruleが適用されます。

MR1ではここに実運用上の問題がありました。SophosのNC-181885によると、Restrict client traffic during identity probe = Yesでは反復Identity Probeが断続的中断を起こす、またはMR1 upgradeをblockする場合がありました。MR2がfix versionとして示され、同時にdefaultもNoへ変わります。

Noならprobe中もclient trafficが流れます。中断は減りますが、判断のバランスが変わります。

• userの中断が減る。
• probe中はfirewallが確定identityを持たない可能性がある。
• この移行時間のuser-based ruleとloggingを正確に確認する必要がある。

availabilityと厳密なidentity enforcementのtrade-offです。Yesではcollector通信障害がclientをblockできます。Noではidentity確定前にtrafficが流れる可能性があります。それが一般network rule、未認証rule、後のuser ruleのどれにmatchするかは独自rulesetでtestが必要です。

release noteは既定値がNoへ変わると述べるだけで、意図的に設定された既存値をすべて上書きするとは明記していません。upgrade後に実際の値を確認してください。

さらに次を確認します。

• firewallとcollector間でUDP 6060と6677が開いているか
• STAS Serviceが稼働し、正しいNICへbindされているか
• fault tolerance用に複数collectorをgroup化しているか
• printer、IoT、非domain device用のClientless User objectがあるか
• sleep、roaming、DHCP変更、logoff後にmappingが正しいか
• Learning Modeと未認証状態のruleがsecurity designどおりmatchするか

identityをreportだけでなく実際のaccess条件にする環境では特に重要です。

Novell eDirectoryはSFOS 23.0で終了

MR2は、SophosがSFOS 23.0でNovell eDirectory authentication serverのサポートを終了することを初めて早期表示します。

MR2ではeDirectoryが引き続き動作します。即時機能停止ではなく事前警告です。ただしproduction利用者はSFOS 23.0導入前に対応認証方式へ移行すべきです。

migrationはserver entryの交換だけではありません。group、firewall rule、web policy、VPN access、user portal、reportingが従来identity sourceに依存する可能性があります。Distinguished Name、nested group、search path、username formatの差により、LDAP test成功だけではpolicy migration成功を証明できません。

またSTASはeDirectoryでLDAP over SSL/TLSを以前からサポートしていません。完全削除はまったく意外ではありませんが、代替architectureはtest account、並行group、文書化したrule reference、rollback planを伴うprojectとして準備する必要があります。

Let’s Encrypt：新しいchainと識別改善

Let’s Encryptはcertificate infrastructureを新しいrootおよびintermediate certificateへ段階的に移行しています。MR2はYE Root、YE1、YE2、YR Root、YR1、YR2をサポートします。

Generation Y hierarchyには異なるkey typeの2つの新Root CAがあります。

• ISRG Root YEはECDSA P-384で、従来ECDSA hierarchyの後継pathです。
• ISRG Root YRはRSA 4096で、新RSA root pathです。
• YE1とYE2はECDSA P-384 intermediateです。
• YR1とYR2はRSA 2048 intermediateです。

rootは既存ISRG rootでcross-signされています。browserやOS vendorが新rootをTrust Storeへ追加する間も、新chainを広く普及済みのtrust anchorへ接続できます。YE1、YE2、YR1、YR2 intermediateは2026年にactive issuanceで重要になりました。

SFOSでは主にcompatibility変更です。自動発行、renewal、WAF利用、validationが新世代Let’s Encryptでも動くには、新issuerとchainを認識する必要があります。trust chainが古ければ、domain、port 80、HTTP-01 validationが正しくてもcertificate operationが失敗する可能性があります。

ACME errorはDNS、DNAT、port 80、WAF rule、Terms of Serviceの問題と誤認しやすく、実際の原因が新CA chainなら運用上厄介です。

SFOSは引き続きHTTP-01を使用します。domainのFQDNが選択public WAN addressを指し、port 80がfirewallへ届く必要があります。同じaddressとport 80を使う競合DNAT ruleはvalidationを妨げます。MR2はこの基本原則を変えず、対応CA hierarchyを拡張します。

さらにLet’s Encrypt email通知へfirewall hostnameとserial numberが追加されます。MSPや大規模環境では非常に有用です。汎用messageだけで調査せず、警告を正しいdeviceへすぐ割り当てられます。

小さくても実用的なquality-of-life改善です。本来、集中管理firewallのsystem messageにはhostname、serial number、model、firmwareが最低限必要です。backup emailに続き、Let’s EncryptもMR2で改善されました。

Config Studio 2.6：すべての新機能

SophosはConfig Studio 2.6をMR2 announcementの一部として扱いますが、これはSFOS内の新画面ではなく、独立したbrowser-based toolです。基本workflowは以前の記事Sophos Firewall Config Studio V2：viewer以上のツールで、export、Entities.xml、comparison、editorまで説明しています。

Sophosによると、parsing、analysis、report生成はendpoint上のbrowserでlocal処理され、設定はSophosその他のserverへ送信されません。Entities.xmlにはinternal network、object、rule、VPN definition、certificate reference、組織名が含まれ得るため、重要な点です。

local処理でも自動的に無riskではありません。browserはapplicationをinternetからloadします。高機密環境ではcode version、browser cache、offline利用、endpoint hardening、exportの安全な保管も検討が必要です。Entities.xmlを無管理でDownloads、ticket、通常のcloud syncへ置くべきではありません。

Config Studio 2.6は5つの作業領域をカバーします。

• Policy Test、analysis、global searchを備えたConfiguration Report
• 2つ以上のconfiguration比較
• bulk editingとXML、API、curl出力を備えたvisual editor
• Sophos UTM、SonicWall、FortiGate、Palo Alto Networksからのmigration
• backup restore、Flexi Port、transceiver、model compatibility

Templateのmerge

Merge Templatesではbaseline configurationと業種別templateを結合できます。MSPならlogging、DNS、admin access、standard objectの技術baselineに、医院、学校、branch向けtemplateを合わせられます。

再利用でfirewallごとにゼロから始めずに済みますが、conflict処理が重要です。

• 同じobject名で値が違う場合はどうなるか
• UUID、reference、rule orderは一貫して解決されるか
• target modelに合わないinterface/zone referenceは何か
• mergeでduplicateまたはoverlap ruleが生まれないか
• 制限的objectが広いtemplate値に置換されないか

merge後はDuplicate Analysis、Shadow Rule Analysis、Usage References、完全なPolicy Testが必須です。技術的に成功したmergeはsecurityを証明しません。

改善されたglobal search

global searchはconfiguration objectを素早く見つけ、その場所へ移動します。大規模rulesetでは1つのhost objectがfirewall、NAT、TLS、web、VPNから参照されます。data typeにより値、path、referenced elementも検索対象です。Server、LAN_Network、長年成長したhost groupのような汎用名ではdirect jumpが特に有用です。

searchはUsage Referenceと同じではありません。searchは「このobjectまたは値はどこか」、Usage Referenceは「どの設定が依存するか」に答えます。安全な変更には両方が必要です。そして、この機能こそfirewall本体の画面に必要です。

詳細なconfiguration report

reportはfirewall、NAT、TLS ruleでreference名だけでなく、利用objectの値と詳細も表示します。Webserver-Gruppeという名前だけでなく、中身のhostやnetworkを確認できます。きれいな名前でもAny、広すぎるnetwork、古いentryを含む可能性があります。

reportはPolicy Testとanalysisにも対応します。Policy Testは指定source/destinationにmatchするruleまたはrouteを調べます。analysisはshadowingやduplicateを検出します。SFOSはfirewall ruleを上から評価し、最初のmatchで停止するため、順序は表示ではなくsecurity logicです。

Config Studio 2.6：migration、comparison、export

成功率を含むmigration analysis

Config Studioはmigrationとconversionの情報、成功した割合を表示します。percentageは素早い指標であり、受入試験報告ではありません。

Sophosは次のstatusを区別します。

• Supported：内容を変更せず自動migration
• Partial：不足を残してmigrationし、補完が必要
• Manual：Sophos Firewallで手動再作成が必要
• Not supported：migrationされない
• Action required：export前に判断が必要

95%のconversionでも、残り5%がcertificate、password、VPN、NAT、特殊routingかもしれません。価値があるのは緑のpercentageではなく、未対応、部分対応、自動解決されたelementの一覧です。

vendor modelには実際の差があります。FortiGate ruleはinterface指向が強く、SFOSはzoneを使います。Palo Altoではobject、zone、policy modelが異なります。Config Studioはsyntaxと多くのstructureを変換できますが、security modelの意味が同じだとは証明できません。

Multi-File Configuration Diff

Multi-File Diffでは2つ以上のconfigurationを時系列で比較できます。Config Studioはfile modification dateで並べ、field levelでadded、removed、changedを示します。

Side-by-Side、Unified、Semantic viewを利用できます。XMLのtext diffは順序、ID、formatのnoiseが多いため、semantic比較が特に興味深い機能です。entity/field level diffは実際の設定変更を見せようとします。

単一maintenance window直後に現れない問題のchange reconstructionやtroubleshootingに有用です。ただし定期的に保存したconfiguration、正しいtimestamp、機密exportの安全な管理が必要です。downloadやcopyしたfileの更新日時はfirewall変更時刻と一致しない場合があります。信頼できる履歴にはfile名、export時刻、hostname、serial number、firmware、change ticketを一緒に記録すべきです。

version管理なしにMulti-File Diffは履歴を作れません。manual uploadより、immutable audit historyとともにCentralへ統合された方がはるかに強力です。

Backup restore、Flexi Port、速度reference

Config StudioはSophos Firewall model間のbackup restore compatibilityとport layoutを確認できます。Flexi Port module、対応port speedとstandardも25、40、100 Gbit/sまで表示します。

hardware migration前に次を確認できます。

• backupを原則restoreできるか
• physical port数
• 既存Flexi Port moduleのcompatibility
• 対応interface standardとspeed

それでもmigration designは必要です。LAG、VLAN、bridge、HA、port名、zone、interface mappingは計画し、restore後に確認します。

広いbackup restore compatibilityはSFOS 20.0 MR2以降のtargetに適用されます。source versionとtarget platformによってBackup-Restore Assistantがinterfaceを割り当てます。physical portはremap可能で、VLANとaliasはparent interfaceに従い、LAGとbridgeは割当portから再構築されます。

Flexi Portでは「物理的に装着できる」だけでは不十分です。model generation、form factor、transceiver、対応standard、port speed、breakout動作、利用可能SFOS versionを合わせて確認します。Config Studioは参照を速めますが、migration後のlink/failover testを代替しません。

Dark Mode

実際のrelease noteはDark Modeも挙げています。小さなusability改善で、firewall機能ではありません。しかし象徴的です。local WebAdmin consoleの外観とergonomicsが何年もゆっくりしか進まない一方、Dark Modeさえ先に外部Config Studioへ入ります。

Editorが技術的に出力できるもの

editorはconfigurationのimportまたは新規作成、Bulk Changesを行い、export前にImport XML、API Request、curlとして結果を表示できます。またXMLまたはTAR archiveをdownloadし、Backup & firmware > Import exportからSFOSへimportできます。

強力な分、管理者の責任も増えます。生成API requestは自動的にidempotentではありません。import成功はRule Order、object利用、NAT、VPN、Security Policyの機能的正しさを証明しません。production適用前にoutputをchange ticketへ入れ、diffをreviewし、実data pathでtestする必要があります。

50件を超えるfixこそMR2の本当の理由

Sophosはreliability、stability、securityに関する50件以上の修正を挙げています。すべての環境に関係するわけではありませんが、重大なものがあります。

HAとfailsafeは周辺的な問題ではない

いくつかのfixは単一機能ではなくapplianceの稼働性に関係します。

• NC-181331：configuration partitionの満杯でfirewallがFailsafe Modeへ入る。
• NC-180110：primaryのLogging Daemonが起動せず、HA deviceがfailsafeへ入る。
• NC-177441：v22 GA upgrade後、Postgres問題で元primaryがfailsafeへ入る。
• NC-178906：RED Server Serviceが起動せずfailsafeを起こす。
• NC-177467：大量の同時未認証SSH接続attemptでauxiliaryが正常起動しない。

原因は異なっても運用結果は同じです。serviceを失い、保護modeへ入り、または緑だったcluster表示と違ってHA peerが利用できません。upgrade後はHA status: Active-Passiveだけでなく、同期、service status、failover、実trafficを確認します。

IPsec fixはdata pathの深部に及ぶ

• NC-180433：VPN tunnel内multicast trafficが反復firewall crashを起こす。
• NC-171719：SD-WAN構成でESP trafficが誤routeに入る。
• NC-180520：IPsec Acceleration有効時、tunnelがalias IPへbindされESPが別WAN portから来ると、upgrade後XFRM gatewayが利用不能のままになる。
• NC-176855：route-based IPsecのIPv6 throughput低下。
• NC-178121：drag-and-dropでFailover Group内site-to-site IPsec connectionが誤位置へ移動する。

これらはtunnel statusがActiveでも正常とは限りません。route-based VPNではXFRM interface、Routing Table、SD-WAN decision、ESP path、MTU、IPv4、IPv6を別々にtestします。Failover Groupでは順序と切替がdocumented priorityどおりか確認します。

Loggingとreporting自体が障害を起こした

NC-155252は特に厄介です。reportingの高disk I/O loadがCPU spikeと最大1分の断続的internet outageを起こしました。analysis subsystemがproduction data pathへ影響した問題です。

NC-178745はLogging Frameworkのout-of-memoryによるHA device自動restart、NC-181520はLog Viewer性能改善です。これらはSFOS loggingが無害な付加機能ではないことを示します。storage、database、Garner、Log Viewer、Central Reportingは画面から想像する以上にsystemへ近接しています。

MR2後は新log lineだけでなく次を確認します。

• firewall、IPS、WAF、authentication、VPN eventが完全か
• timelineにgapがないか
• external syslog collectorがdataを受信し続けるか
• 通常loadでCPU、RAM、disk I/Oが安定するか
• report生成がdata pathへ影響しないか

Central fixが「Single Pane of Glass」の限界を示す

NC-181175ではSophos CentralのGroup PolicyがPendingのままになる場合がありました。NC-180513はMR1 upgrade後のCentral Viewからのconfiguration import、NC-181904はCentralからquarantine mailをreleaseできない問題です。

共通するのは、central interfaceがoperationを受け付けて表示しても、firewallが実行した証拠にならない点です。Group Policy push後はtarget device上でobject、rule、order、timestampが本当に反映されたか確認します。Centralのsuccess dialogは技術的なcommit証明ではありません。

maintenance releaseをfeature listの長さだけで評価できない理由です。logging、Postgres、SD-WAN、multicastでfirewallがfailsafeまたはrestartする問題の修正は、新dashboard tileより価値があります。

しかしfix数はquality certificationでもありません。問題を修正したことと、以前のbuildに重大な問題が多かったことの両方を示します。criticalなHA、VPN、WAF環境は、恐れて古いbuildへ永遠に留まることも、初日に未検証MR2を一斉配布することも避けるべきです。

アップグレード前に確認すべきこと

Sophosはsecurity、stability、performance fixのためMR2を早期にinstallするよう推奨します。基本的には理解できますが、productionで「早期」は「無検証」を意味しません。

Bridgeのlegacy VLAN taggingはMR2をblockする

MR2ではbridge interface上の旧CLI-based VLAN taggingがhard upgrade blockになります。legacy方式system vlan-tagが残るconfigurationはSFOS 22.0 MR2以降へupgradeできません。

事前に整理またはmigrationが必要です。このlegacy設定を含むbackupはSFOS 22.0 GA以降へrestoreできません。過去にCLIで調整された長期運用環境では特に重要です。

従来のv22制約も継続する

• Legacy Remote Access IPsecはMR1またはMR2前に削除またはmigrationが必要。
• SFOS 22はより多くのstorageを必要とし、一部desktop、virtual、software applianceは調整が必要。
• policy-based IPsec VPNの動作はGA以降変わったため該当tunnelを確認。
• XGとSG hardwareはSFOS 22非対応。
• RED 15、RED 15w、RED 50はv21.5以降非対応。

私のアップグレード手順

production firewallでは少なくとも次を行います。

1. 最新backupを作成し外部保存する。
2. support、license status、許可upgrade pathを確認する。
3. Legacy Remote Access IPsecとbridge上CLI VLAN taggingがないことを確認する。
4. Control CenterのDisk Space warningを確認する。
5. HAでは両nodeの状態、同期、利用可能firmwareを確認する。
6. critical VPN、WAF publishing、mail flow、SD-WAN rule、authenticationを記録する。
7. 代表的なtestまたは低critical applianceへ先にMR2をinstallする。
8. upgrade後にlog、pattern、HA、routing、DNS、VPN、WebAdmin、reporting、central policy pushをtestする。

fixが多いreleaseほど、明確なbefore/after testが有用です。そうしなければfirmwareが新しいことだけ分かり、critical data pathが計画どおりとは分かりません。

SFOSはversion 20以降、upgrade中のconfiguration migration失敗時にautomatic firmware rollbackを行います。Factory Configurationで起動するriskを下げますが、unsupported upgrade pathや一部Setup Assistant flowなど、すべてのscenarioを保護しません。自動rollback後はmigration.logとmigrationhash.logを分析します。

automatic rollbackは外部backup、Secure Storage Master Key、利用可能なconsole accessの代わりではありません。主にconfiguration migration失敗から守るだけで、技術的に成功したupgrade後のWAF、VPN、HA、reportingが正しい証拠ではありません。

私のMR2 testでは前後で同じ点を測定または意図的に動作させます。

• rebootと全service startup
• WebAdmin loginと大規模rule listの応答
• localおよびexternal log flow
• IPsec traffic、rekey、failover
• firewall上で確認するCentral Policy Push
• IPSとApplication Controlのpattern update
• STAS再logonと未知client IPの動作
• test systemがclusterならHA同期と制御したrole change

これを終えて初めて自分の環境でMR2が本当に改善したか判断できます。install成功と緑のControl Centerでは不十分です。

最初のcommunity feedbackから分かること

feedback threadはMR2公開日と同日に開始され、この評価時点で数時間しか経っていません。MR2が安定とも問題ありとも判断できません。

それでも2つのdiscussionは注目できます。

• XGS 5500 Active-Passive HAの運用者が、MR1で数か月NC-177467に悩んだためtestの深さを具体的に質問しています。SophosはMR2でfix済みとし、大量の同時未認証SSH接続attemptでauxiliaryが起動しない問題です。
• PQC signatureについてSophos社員は、意図的に無効だと説明します。browserとapplicationでPQC TLSが増えており、すぐに有効化すると大量のalertが出る可能性があります。まずAllowとlogging、必要なら後からblockする方向を推奨しています。

新release初期として合理的です。曖昧な「動く」「壊れた」ではなく、具体的test、case ID、再現可能なfeedbackです。今後もHA、IPsec、WAF、STAS、reportingを中心にthreadを追います。

Config Studioは古い画面の部品倉庫になる

ここからは不快な部分です。

Config Studio 2.6は良いtoolです。template merge、object検索、report内referenceの展開、複数configuration比較、hardware migration準備は本物の管理機能です。私が批判するのはSophosが作ることではなく、作る場所です。

SophosはConfig Studioをfirewall release noteと公式MR2 announcementへ直接載せています。WebAdminまたはSophos Centralで解決すべき問題への戦略的回答に見え始めています。

local firewall UIは依然古く、大規模configurationでは遅いことが多いままです。bulk変更は不十分です。object利用箇所、真のglobal search、明確なdiff、NAT cloning、rule conflict、現代的change workflowが日常作業の画面にありません。Centralが埋めるのは一部だけです。

問題はdesignだけではありません。現代的firewall interfaceには次のchange processが必要です。

• 個別変更の即時反映ではなくCandidate Configuration
• commit前の完全なbefore/after diff
• object、rule、NAT、VPN、TLSを横断するdependency check
• atomic commitまたは明確なtransaction status
• 最終既知状態へのvalidated rollback
• Audit Trailでのuser、time、sourceの実際の関連付け
• previewとconflict check付きBulk Operations
• 再現可能なchangeのための一貫したAPI output

Config Studioは一部をsystem外で再現します。exportを分析し、XMLまたはAPI requestを生成し、diffを支援します。しかしoffline viewとactive runtime stateの間にはgapが残ります。session、dynamic routing、HA state、current pattern、certificate status、実際にloadされたconfigurationは、localのEntities.xmlと同じではありません。

1つのrelease announcementだけで、SophosがSFOS UIを二度と根本刷新しないと断定するのは行き過ぎです。確認済みの発言はありません。それでもsignalは良くありません。usability、search、comparison、configuration作業で最も目立つ進歩が再び実管理interfaceの外へ入ります。

workflowは分断されたままです。

1. firewallからconfigurationをexportする。
2. archiveを展開してEntities.xmlを探す。
3. 別browser toolへfileをloadする。
4. そこで分析、比較、編集する。
5. 結果をexportし、XML、API、curlで戻す。

auditなら許容できますが、現代的で安全かつ追跡可能な管理としては遠回りです。Config Studioは特殊用途だけでなく、Sophos管理者が何年も求めたlow-hanging fruitを受け取っています。

通常のfirewall release noteでConfig Studioを大きく扱うなら、小さな補助toolとは言えません。目に見えてadmin strategyの一部です。どの機能をWebAdminまたはCentralへ統合し、どれをbrowser toolへ残すのかSophosは説明すべきです。

roadmapがなければ、古く、遅く、大規模構成で次第に使いにくいinterfaceを残し、現代的workflowにはConfig Studioを使わせる印象になります。確認されたSophosの計画ではありませんが、製品が現在伝えている方向です。

なぜUniFiにとって容易な市場になるのか

UniFiはすべてのSophos Firewallを完全には代替しません。licenseとarchitectureにより、Sophosはより深いsecurity、IPS、Web Protection、WAF、endpoint integration、MDR/XDR連携、classic enterprise機能を提供します。公平な比較ではその差を無視できません。

しかし体感する製品品質は毎日の操作性で決まります。

Ubiquitiはdesign、mobile app、一貫したnavigation、topology、簡単なdevice onboarding、長年の製品経験がなくても分かるinterfaceへ目に見えて投資しています。すべてのUniFi機能が技術的に深いわけではありませんが、製品は現代的に感じられます。traditional firewall vendorが考える以上に購買判断へ影響します。

小規模IT teamはIPS datasheetだけを見ません。次も見ます。

• device、rule、clientをどれだけ早く見つけられるか
• smartphoneから環境を適切に確認できるか
• 専門知識なしにwarningとdependencyを理解できるか
• 日常変更に何click必要か
• 一体的platformか、複数toolの寄せ集めに見えるか

SophosはUbiquitiのようなvendorへ不必要に好機を与えています。security面ではSophos Firewallがより多くを提供し、多くのSMBでは今も合理的な選択です。しかしmodern search、diff、template、bulk changeに別Config Studioが必要で、core interfaceが古く遅いままなら、最も目に見える層で信頼を失います。

良いsecurityには強いengineだけでなく、人がruleを理解し、errorを見つけ、安全に変更できるinterfaceが必要です。usabilityは外観上の追加要素ではなく、operational securityの一部です。

結論：MR2は導入するが、製品の問題は残る

SFOS 22.0 MR2は大規模feature releaseではありません。意味のある追加を含む重要なmaintenance releaseです。

PQC制御は適切な時期に来ましたが、まず観察modeで導入すべきです。生成AI applicationの検出改善は可視性とpolicyに役立ちますが、DLPやAI governanceを代替しません。Chromebook管理者はManifest V3 extensionを能動的に配布する必要があります。STASは中断が減る一方、identity ruleを意識して確認しなければなりません。Let’s Encryptは次世代certificate chainへ備えます。そして多数のfixはproductionで実際の停止を起こし得る問題を修正します。

私はbackupとpreflight後すぐにMR2をinstallし、これらdata pathをtestします。記載HA、VPN、reporting、Central、failsafe問題の影響を受けるなら、updateする理由があります。Build 546が本当に安定するか、新regressionを持ち込むかはrelease当日に責任を持って答えられません。

批判は変わりません。Config Studio 2.6は有用でも、firewall releaseでの大きな役割は、Sophosが現代的管理をside toolへ移している印象を強めます。新しいSFOS interfaceの放棄が確認されたわけではありませんが、戦略的warning signです。

Sophosには強いfirewall基盤があります。その技術基盤にふさわしいmanagement experienceを管理者へ提供すべきです。そうしなければ、現代的platformは必ずしもsecurityが優れるからではなく、画面の前の人を真剣に扱うことで勝つでしょう。

それでは、また次回。
Joe

FAQ