Sophos Firewall v22 MR2: تحديث أم مخاطرة جديدة؟

صدر Sophos Firewall v22 MR2. نُشرت النسخة 546 في 14 يوليو 2026، وهي تجمع بين وظائف أمنية مفيدة وتغييرات في المصادقة وتحديثات للشهادات وأكثر من 50 إصلاحاً للأخطاء.

على الورق، هذا Maintenance Release تقليدي. لكن عملياً يحتوي بالضبط على المزيج الذي يجعلني أتفحص إصدارات Sophos مرتين: منطق اكتشاف جديد في IPS، وسلوك مختلف لربط المستخدمين، وسلاسل شهادات جديدة، وفي الوقت نفسه قائمة طويلة من أعطال kernel ومشكلات HA وحالات Failsafe وأخطاء VPN وانقطاعات reporting.

ليست هذه أخباراً إيجابية فقط. إصلاح أكثر من 50 خطأ يعني أن Sophos تنظف المنتج، لكنه يكشف أيضاً عدد المشكلات الخطيرة التي بقيت في GA وMR1. سبق أن انتقدت جودة firmware هذه في Sophos Firewall: لا توجد CVE، لكن توجد أخطاء (من v21.5 إلى v22).

سأثبت MR2 فوراً على أحد أجهزة Sophos Firewall الخاصة بي. ليس لأنني أثق بالإصدار ثقة عمياء في يومه الأول، بل لأرى هل تهدئ النسخة 546 خط v22 أخيراً أم تظهر مجدداً أخطاء جديدة أكثر مما يصلحه التحديث. سأراقب خصوصاً HA وlogging وIPsec واستجابة WebAdmin وSTAS والاستقرار بعد تحديثات patterns.

وفي الوقت نفسه تصنع Sophos تناقضاً غريباً. أصبح Config Studio 2.6 يحتل مساحة كبيرة في تحديثات firewall الرسمية. تحصل أداة المتصفح الخارجية على دمج templates وبحث أفضل وMulti-File Diffs وتحليل ترحيل وبيانات توافق hardware، بينما لا يحدث تقريباً أي تغيير مرئي في الإدارة اليومية داخل واجهة firewall نفسها.

لذلك أرى MR2 مهماً تقنياً لكنه محبط استراتيجياً. يحصل محرك الأمن على وظائف جديدة، بينما تُنقل workflows الإدارة الحديثة مرة أخرى إلى Config Studio.

أهم النقاط باختصار

يحمل SFOS 22.0 MR2 رقم النسخة 546 ويأتي بعد MR1 build 490. تبرز Sophos سبعة مجالات رئيسية:

• اكتشاف التشفير ما بعد الكمي والتحكم فيه؛
• تصنيف أفضل لتطبيقات الذكاء الاصطناعي التوليدي؛
• إضافة Chromebook User ID جديدة تعتمد Manifest V3؛
• تغيير السلوك الافتراضي لـ STAS؛
• إعلان مبكر عن انتهاء دعم Novell eDirectory في SFOS 23.0؛
• سلاسل ثقة جديدة لـ Let’s Encrypt وإشعارات بريد أفضل؛
• Config Studio 2.6 بوظائف تحليل وترحيل ومقارنة جديدة.

تضاف إلى ذلك أكثر من 50 مشكلة أُصلحت. بعض هذه الإصلاحات أهم تشغيلياً من الوظائف الجديدة، لأنها تشمل أعطال kernel ومشكلات HA وحالات Failsafe وأخطاء VPN ومشكلات أداء reporting.

تقييمي المختصر:

• من يشغّل v22 GA أو MR1 ويتأثر بأحد الأخطاء المدرجة لديه سبب واضح لتثبيت MR2.
• لا ينبغي ترقية تثبيت 21.5 مستقر على عجل لمجرد PQC أو Config Studio.
• يجب تشغيل توقيعات PQC أولاً للمراقبة فقط، لا فوراً بإجراء Drop.
• على بيئات STAS التحقق بعد الترقية من معاملة traffic غير المصادق عليه أثناء Identity Probe.
• تحتاج بيئات HA وIPsec وWAF والبريد وreporting إلى اختبارات فعلية، لا مجرد النظر إلى مؤشرات خضراء.
• Config Studio 2.6 مفيد تقنياً، لكنه ليس دليلاً على تحديث واجهة SFOS WebAdmin. بل العكس على الأرجح.

يبقى حد hardware مهماً: لم يعد SFOS 22.0 يدعم أجهزة XG وSG. الإصدار مخصص لـ XGS والتثبيتات الافتراضية والبرمجية وcloud المدعومة. لذلك لا يستطيع من لا يزال يستخدم XG اعتبار MR2 خطوة firmware عادية تالية.

اكتشاف التشفير ما بعد الكمي والتحكم فيه

أكثر الإضافات إثارة تقنياً هي التحكم في Post-Quantum Cryptography أو PQC. لا يعني ذلك أن Sophos Firewall يصد حواسيب كمومية فجأة، بل تتعلق الوظيفة بآليات حديثة لتبادل المفاتيح صُممت لتكون أقوى أمام هجمات مستقبلية بحواسيب كمومية قوية.

يركز MR2 على ML-KEM. وُحّد هذا الأسلوب عام 2024 في FIPS 203 ويعتمد على الصعوبة المفترضة لمسألة Module Learning With Errors. يحدد NIST ثلاثة مستويات:

• ML-KEM-512 بأصغر مفاتيح وحجم بيانات؛
• ML-KEM-768 كخيار متوسط واسع الاستخدام حالياً؛
• ML-KEM-1024 بمستوى أمان أعلى وكلفة حساب ونقل أكبر.

تتحدث Sophos في وثائق MR2 بصورة عامة فقط عن خوارزميات تبادل مفاتيح ML-KEM الخالصة والهجينة. ولا تكشف مستويات parameters أو مجموعات TLS أو IDs التوقيعات المشمولة. لذلك لا ينبغي افتراض اكتشاف كل صيغة ML-KEM ممكنة.

ماذا يفعل KEM تقنياً؟

لا يشفّر ML-KEM تدفق البيانات كله مباشرة. يتكون Key Encapsulation Mechanism بصورة مبسطة من ثلاث عمليات:

1. ينشئ KeyGen مفتاح Encapsulation Key ومفتاح Decapsulation Key المقابل.
2. ينشئ Encaps باستخدام المفتاح العام كائن Ciphertext وسراً مشتركاً.
3. يستعيد Decaps السر نفسه في الطرف الآخر بواسطة المفتاح الخاص.

يشتق البروتوكول بعد ذلك مفاتيح session متماثلة من السر المشترك. وتظل البيانات الفعلية محمية بخوارزميات متماثلة سريعة مثل AES أو ChaCha20. أي أن ML-KEM يستبدل الجزء غير المتماثل المعرض للخطر في تفاوض المفاتيح، لا تشفير TLS كله.

الخلفية العملية هي Harvest now, decrypt later: يستطيع مهاجم تسجيل traffic مشفر اليوم على أمل فك تشفيره بعد سنوات بحاسوب كمومي ذي قيمة تشفيرية. يقل الخطر للبيانات قصيرة العمر، لكنه مهم للبيانات الطبية والاتصالات الحكومية والملكية الفكرية والبيانات السرية طويلة الأمد.

الخالص والهجين ليسا الشيء نفسه

في تبادل PQC خالص يعتمد أمان التفاوض على الأسلوب ما بعد الكمي الجديد وحده. أما التبادل الهجين فيجمع آلية تقليدية مع ML-KEM. ومن أمثلته الشائعة X25519MLKEM768، حيث يساهم X25519 التقليدي وML-KEM-768 معاً في السر النهائي.

النهج الهجين منطقي حالياً. فإذا ظهر خلل implementation أو ضعف رياضي في ML-KEM بقي الجزء التقليدي. وإذا كسر حاسوب كمومي المنحنى الإهليلجي التقليدي بقي جزء ML-KEM. الهجين جسر للانتقال، وليس تشفيراً مزدوجاً بلا داعٍ.

لكن X25519MLKEM768 هنا مثال تقني حقيقي من تطبيقات TLS الحالية. لا تقول Sophos إن هذه المجموعة هي الوحيدة أو الأساسية التي يكتشفها MR2.

ماذا يفعل IPS؟

يحصل Intrusion Prevention System على توقيعات جديدة لاكتشاف تبادل مفاتيح ML-KEM الخالص والهجين. ويمكن للمسؤولين إنشاء قواعد IPS مخصصة واختيار Allow أو Drop أو Reset.

تستطيع firewall تقنياً رؤية تبادل المفاتيح المقترح والمختار في TLS handshake: يعلن العميل المجموعات وKey Shares المدعومة في ClientHello، ويؤكد الخادم اختياره في ServerHello. يحدث ذلك قبل تدفق التطبيق المشفر، لذلك يمكن الاكتشاف من دون قراءة محتوى HTTPS اللاحق.

لكن Sophos لا توثق أين يحلل Snort أو SFOS IPS pipeline هذه السمات، ولا إصدارات TLS المشمولة، ولا الفروق بين proxy وDPI وFastPath غير المفكوك. تؤكد Release Notes القدرة، لا تنفيذها الداخلي في مسار البيانات. لذلك تحتاج policy الإنتاج إلى اختبار فعلي مع firewall وIPS logs.

للإجراءات آثار مختلفة:

• يسمح Allow بالاتصال، وهو مناسب مع logging للجرد الأولي.
• يتخلص Drop بصمت من الحزم المطابقة، فيرى العميل عادة timeout أو handshake مقطوعاً.
• ينهي Reset اتصال TCP نشطاً، فيظهر الخطأ أسرع لكنه قد يبدو مختلفاً للمستخدم وفي application logs.

التوقيعات الجديدة معطلة افتراضياً، وهذا صحيح. لم تعد PQC تقنية مختبرية؛ تختبر متصفحات وخدمات cloud ومنصات web كبيرة الأساليب الهجينة أو تستخدمها. وقد يؤدي حظرها الشامل إلى تعطيل مواقع وتطبيقات شرعية.

يكون النشر المنطقي هكذا:

1. تفعيل التوقيعات أولاً مع السماح بالـ traffic وتسجيله.
2. تحليل التطبيقات والوجهات التي تستخدم ML-KEM على مدى أيام أو أسابيع.
3. التحقق مما إذا كانت سياسات التشفير الداخلية تمنع أساليب معينة أو تفرضها.
4. تطبيق Drop أو Reset بصورة موجهة بعد ذلك فقط.

في أول نقاش للمجتمع، قال مسؤول بعد الترقية إنه لم يجد توقيعات IPS بعبارات PQC أو KEM أو quantum. قد يكون السبب تحديث patterns لم يصل بعد أو طريقة التسمية. لا يمكن اعتباره خطأ مؤكداً بعد ساعات من النشر، لكنه يكشف مشكلة توثيق: لا يمكن إدارة وظيفة ما إلا إذا أمكن العثور على اسم توقيعها وSID وفئتها وخصائص log.

قبل تغيير policy سأتحقق من:

• هل IPS نشط واشتراك Network Protection صالح؟
• ما إصدار IPS patterns المثبت؟
• تحت أي اسم وSID تظهر التوقيعات؟
• هل تظهر النتائج في IPS log وreporting المركزي؟
• هل يبقى الاكتشاف نفسه مع استثناءات DPI وTLS Inspection وFastPath؟
• أي متصفحات وأنظمة تشغيل وخدمات cloud وتطبيقات داخلية تولد النتائج؟

ماذا يفعل Web Protection؟

تقول Sophos أيضاً إن Web Protection يمنع جلسات web من تفاوض خوارزميات PQC غير المدعومة. وهذه مهمة مختلفة عن توقيع IPS. يكتشف IPS أنماطاً ويتفاعل معها، بينما يتدخل Web Protection في workflow TLS وweb لمنع آلية لا تستطيع firewall معالجتها أو لا تسمح بها policy.

يهم ذلك خصوصاً مع TLS Inspection. ففي الاتصال المفكوك تنهي firewall جلسة TLS مع العميل وتنشئ جلسة TLS ثانية مع الخادم. توجد عمليتا handshake ومجموعتان منفصلتان من مفاتيح session. وقد يدعم المتصفح والخادم PQC بينما لا يستطيع مكون inspection الوسيط معالجة المجموعة المقترحة.

من دون سلوك مضبوط تظهر أخطاء صعبة الفهم: يقترح العميل مجموعة جديدة، ولا تتمكن firewall من الوساطة الكاملة، أو يختار الخادم خياراً غير متوقع، أو يتصرف fallback بشكل مختلف. يفترض أن يمنع MR2 تفاوض الخوارزميات غير المدعومة.

المهم أيضاً ما لا توضحه Sophos: لا توجد مصفوفة PQC policy لـ Web Protection، ولا قائمة مجموعات مدعومة، ولا بيان دقيق هل يُحذف العرض غير المدعوم أم يُرفض أم يُستبدل بـ fallback تقليدي. ولا ينبغي مساواة ذلك بإجراء IPS القابل للضبط.

الوظيفة مفيدة لكنها لا تستبدل استراتيجية تشفير. لا بد أن تعرف الشركات أي اتصالات TLS تُفك، وأين توجد الاستثناءات، وهل تراقب PQC فقط أم تفرضها.

رؤية أفضل لتطبيقات الذكاء الاصطناعي التوليدي

تتعلق الوظيفة الأمنية الثانية بتطبيقات الذكاء الاصطناعي التوليدي. تحسن Sophos تصنيفها عبر Synchronized Application Control.

المبدأ ليس جديداً: يعرف Sophos Endpoint أي process محلي ينشئ الاتصال، وينقل سياق التطبيق إلى firewall عبر Security Heartbeat. وبذلك تربط firewall الجلسة ببرنامج حتى إذا لم يكف port وIP الوجهة والـ traffic المشفر للتعريف الدقيق.

مسار البيانات المبسط:

1. يفتح تطبيق على endpoint محمي اتصال شبكة.
2. يعرف Sophos Endpoint اسم process ومساره وسياقه المحلي.
3. يربط Security Heartbeat رؤية endpoint برؤية firewall.
4. ينسب SFOS الجلسة المجهولة أو المعروفة بصورة عامة إلى تطبيق.
5. يظهر التطبيق في Synchronized Application Control ويمكن تصنيفه.
6. تسمح Application Filter Policy بالـ traffic أو تحظره أو تنظمه.

يمكن لـ SFOS في Connection List طلب معلومات عن الاتصال غير المعروف عبر Resolve application info. ويمكن البحث بالاسم أو المسار أو الفئة أو endpoints. تذكر Sophos حداً أقصى قدره 15,000 تطبيق، وتحتفظ firewall بآخر خمس مرات لكل تطبيق وendpoint لتوفير الذاكرة.

يحسن MR2 ربط تطبيقات الذكاء الاصطناعي التوليدي تحديداً. يفترض أن يتعرف Sophos Endpoint عليها بدقة أكبر ويرسل المعلومات إلى firewall. توجد فئة Generative AI في قائمة SFOS ويمكن استخدامها في Application Filters وReports.

تهم المسؤولين ثلاثة أمور:

• الرؤية: يجب أن يوضح reporting تطبيقات الذكاء الاصطناعي التوليدي المستخدمة.
• القواعد: يمكن السماح بالتطبيقات أو تقييدها أو حظرها بدقة أكبر.
• الجرد: تحصل فرق الأمن وحماية البيانات على أساس للتمييز بين خدمات AI المعتمدة وغير المعتمدة.

هذا مفيد، لكن لا ينبغي المبالغة في معنى «اكتشاف الذكاء الاصطناعي التوليدي».

يجيب Synchronized Application Control أساساً عن: أي تطبيق أنشأ الاتصال؟ ولا يحدد تلقائياً:

• prompt الذي أدخله المستخدم؛
• الملف الذي رفعه؛
• وجود بيانات شخصية أو سرية؛
• ما إذا كانت browser session شخصية أم مهنية؛
• استخدام خدمة AI مسموحة عبر وظيفة مدمجة في المتصفح.

تعريف desktop client بمسار process واضح أسهل من عشر خدمات AI تعمل كلها في process المتصفح نفسه. قد تضيف URL categorization وTLS Inspection وCloud App detection معلومات، لكنها طبقات اكتشاف مختلفة تقنياً.

وتعتمد الفائدة على Sophos Endpoint وSecurity Heartbeat نشط وتفعيل Synchronized Application Control أول مرة عبر Sophos Central. من يستخدم SFOS من دون Sophos Endpoint أو لديه endpoints خارج Heartbeat لا يحصل تلقائياً على العمق نفسه.

التوقع الصحيح: يحسن MR2 ربط التطبيقات وأساس policies، لكنه لا يحل وحده قرار الخدمات المسموحة والبيانات التي يمكن معالجتها فيها.

لن أحظر فئة Generative AI كلها فور الترقية. يجب أن يوضح reporting أولاً ما جاء من سياق endpoint أو توقيع firewall أو web categorization، وإلا قد تُحظر وظائف منتجة في Microsoft 365 أو أدوات التطوير أو المتصفحات أو منصات الدعم.

تغييرات المصادقة وربط المستخدمين

يقدم MR2 ثلاثة موضوعات مستقلة للمصادقة. اثنان يحتاجان إلى إعداد عملي، والثالث تحذير ترحيل مبكر.

Chromebook User ID مع Manifest V3

انتقلت إضافة Sophos Chromebook User ID إلى Manifest V3، منصة إضافات Chrome الحالية التي تستبدل الأساس القديم.

النقطة الحاسمة: تطلب Sophos إزالة الإضافة القديمة وتثبيت الجديدة. لا يكفي تحديث صامت. على المدارس والشركات التي تدير Chromebook مركزياً إعداد التغيير في Google Admin واختباره على مجموعة صغيرة ثم تعميمه.

تقنياً الإضافة جزء واحد فقط من SSO. يتطلب Chromebook SSO، من بين أمور أخرى:

• خادم AD أو LDAP أو Google Secure LDAP على firewall؛
• أجهزة Chromebook داخل شبكة يحميها SFOS؛
• عناوين مستخدمين من نطاق Google Workspace المسجل؛
• شهادة للاتصال المشفر؛
• CN يطابق الشهادة؛
• منفذ Sophos الافتراضي 65123؛
• إعداد JSON مصدّر من SFOS ومحفوظ في Google Workspace؛
• وصولاً إلى accounts.google.com وGoogle API Hosts وChrome Web Store.

توزع الإضافة في Devices > Chrome > Apps and extensions > Users and browsers. يُنصح بـ Force install في الإنتاج حتى لا يزيلها المستخدم. ويجب الوثوق بـ Sophos User ID App في API Controls، وإلا قد يفشل OAuth.

بعد التغيير، لا يكفي التحقق من التثبيت. المهم هو السلسلة كاملة:

1. يسجل المستخدم الدخول إلى Chromebook.
2. تصل الإضافة إلى firewall عبر الشبكة والشهادة المحددتين.
3. يظهر المستخدم في Live users.
4. تطابق قاعدة مبنية على المستخدم فعلاً المستخدم أو المجموعة.
5. بعد تسجيل الخروج أو تبديل الجهاز، تختفي العلاقة بصورة صحيحة.

من دون الإضافة الجديدة قد تتوقف التحديثات المستقبلية. وبحسب تصميم المصادقة، قد يتأثر ربط المستخدم وبالتالي قواعد firewall أو web المبنية عليه. وفي مدرسة قد تصبح سريعاً مشكلة filtering رغم أن firewall والإنترنت وChromebook تبدو كلها “online”.

STAS لا يحظر أثناء فحص الهوية افتراضياً

يغير MR2 القيمة الافتراضية في Sophos Transparent Authentication Suite لإعداد Restrict client traffic during identity probe إلى No.

يربط STAS عناوين IP بالمستخدمين الذين يكتشفهم Windows Domain Controller. والمسار التقني هو:

1. يسجل المستخدم الدخول إلى نطاق Windows.
2. يكتب Domain Controller حدث Security Audit، عادة Event ID 4768 في Windows الحديث.
3. يستخرج STAS Agent اسم المستخدم وIP.
4. يرسل Agent المعلومات افتراضياً إلى Collector عبر TCP 5566.
5. يبلغ Collector firewall بالربط الناجح عبر UDP 6060.
6. عند رؤية traffic من IP مجهول، يستعلم SFOS من Collector على port 6677.
7. تضيف firewall عضوية المجموعة عبر خادم AD وتطبق القواعد المبنية على المستخدم.

إذا لم يوجد ربط لـ IP، يدخل Learning Mode. سابقاً كان traffic يتوقف أو يُرفض أثناء الفحص افتراضياً لمدة موثقة 120 ثانية. وإذا لم يرد Collector فقد يعد IP غير مصادق عليه لمدة ساعة، ثم تطبق قواعد traffic غير المصادق عليه.

هنا ظهرت مشكلة تشغيل حقيقية في MR1. توثق Sophos NC-181885: مع Restrict client traffic during identity probe = Yes كانت Identity Probes المتكررة تسبب انقطاعات أو تمنع ترقية MR1. MR2 هو الإصدار المصلح ويغير الافتراضي إلى No.

مع No يستمر traffic أثناء الفحص. يقلل ذلك الانقطاع لكنه يغير الموازنة:

• يتعرض المستخدم لانقطاعات أقل؛
• قد لا تملك firewall هوية مؤكدة أثناء الفحص؛
• يجب فحص قواعد المستخدم وlogging بدقة خلال المرحلة الانتقالية.

إنها مفاضلة بين التوافر وفرض الهوية الصارم. قد يحظر Yes العميل عند فشل Collector، بينما يسمح No بالـ traffic قبل تأكيد الهوية. يجب اختبار هل يطابق قاعدة شبكة عامة أم قاعدة غير مصادق عليها أم لاحقاً قاعدة مستخدم.

تقول Release Notes إن القيمة الافتراضية تصبح No، ولا تؤكد استبدال إعداد موجود اختير عمداً. لذلك يجب التحقق من القيمة الفعلية بعد الترقية.

وسأتحقق أيضاً من:

• هل UDP 6060 و6677 مفتوحان بين firewall وCollector؟
• هل STAS Service يعمل ويرتبط بـ NIC الصحيحة؟
• هل توجد Collectors متعددة في مجموعات Fault Tolerance؟
• هل تغطي Clientless User objects الطابعات وIoT والأجهزة خارج النطاق؟
• هل يظهر المستخدمون بعد Sleep وRoaming وتغيير DHCP وLogout؟
• هل تطابق القواعد أثناء Learning Mode والحالة غير المصادق عليها تصميم الأمن؟

هذا مهم خصوصاً عندما تكون هوية المستخدم شرط وصول فعلياً، لا مجرد مصدر reporting.

نهاية Novell eDirectory مع SFOS 23.0

يعلن MR2 مبكراً للمرة الأولى أن Sophos ستنهي دعم خوادم مصادقة Novell eDirectory في SFOS 23.0.

يستمر eDirectory بالعمل في MR2. إنه تحذير وليس فقداناً فورياً للوظيفة. لكن على من يستخدمه في الإنتاج الانتقال إلى نوع مصادقة مدعوم قبل تثبيت SFOS 23.0.

لا يشمل الترحيل server entry فقط. قد تعتمد عليه groups وقواعد firewall وWeb Policies وVPN وبوابات المستخدم وreporting. كما قد تجعل اختلافات Distinguished Names وتداخل groups ومسارات البحث وصيغ أسماء المستخدمين اختبار LDAP الناجح بعيداً عن ترحيل policies ناجح.

وهناك حد قديم: لا يدعم STAS مع eDirectory بروتوكول LDAP عبر SSL/TLS. لذلك ليست الإزالة الكاملة مفاجئة تماماً، لكن يجب تجهيز البديل كمشروع مستقل بحسابات اختبار ومجموعات موازية ومراجع قواعد موثقة وخطة رجوع.

Let’s Encrypt: سلاسل جديدة وتعريف أفضل

تنقل Let’s Encrypt بنية الشهادات تدريجياً إلى Root وIntermediate certificates جديدة. يضيف MR2 دعم YE Root وYE1 وYE2 وYR Root وYR1 وYR2.

تتكون Generation Y hierarchy من Root CAs جديدتين بمفتاحين مختلفين:

• يستخدم ISRG Root YE ‏ECDSA P-384 وهو مسار خلافة ECDSA السابق.
• يستخدم ISRG Root YR ‏RSA 4096 وهو مسار RSA Root الجديد.
• YE1 وYE2 هما Intermediates ‏ECDSA P-384.
• YR1 وYR2 هما Intermediates ‏RSA 2048.

تحمل Roots توقيعاً متقاطعاً من ISRG Roots السابقة. وبذلك تعود السلاسل الجديدة إلى Trust Anchors منتشرة بينما تضيف الأنظمة والمتصفحات Roots الجديدة إلى Trust Stores. وأصبحت Intermediates YE1 وYE2 وYR1 وYR2 ذات صلة بالإصدار الفعلي عام 2026.

بالنسبة إلى SFOS، هذا تحديث توافق أساساً. يجب أن تعرف firewall الجهات والسلاسل الجديدة كي تستمر الإصدار التلقائي والتجديد واستخدام WAF والتحقق. ومن دون سلسلة ثقة محدثة قد تفشل عمليات الشهادة رغم صحة domain وport 80 وHTTP-01.

يسهل تشخيص خطأ ACME على نحو خاطئ، بالبحث في DNS أو DNAT أو port 80 أو قاعدة WAF أو Terms of Service بينما السبب سلسلة CA جديدة.

يواصل SFOS استخدام HTTP-01 لطلبات Let’s Encrypt. يجب أن يشير FQDN إلى WAN العام المختار، وأن يصل port 80 إلى firewall؛ وقد تمنع قاعدة DNAT منافسة على العنوان والمنفذ نفسيهما التحقق. لا يغير MR2 هذا المبدأ بل يوسع CA hierarchy المدعومة.

وتتضمن رسائل Let’s Encrypt الآن hostname وserial number. يبدو ذلك صغيراً لكنه مفيد لـ MSP والبيئات الكبيرة، إذ يسهل تحديد الجهاز الصحيح بين عشرات firewalls.

إنه تحسين Quality of Life عملي. يجب أن تحتوي كل رسالة نظام على hostname وserial number وmodel وfirmware على الأقل. اتجهت Sophos إلى ذلك مع رسائل backup، وتلحق Let’s Encrypt بها في MR2.

Config Studio 2.6: شرح كل وظيفة جديدة

تعرض Sophos ‏Config Studio 2.6 رسمياً ضمن إعلان MR2، رغم أنها أداة browser منفصلة وليست واجهة داخل SFOS. يشرح المقال السابق Sophos Firewall Config Studio V2: أكثر من مجرد viewer workflow الكامل مع export وEntities.xml والمقارنة وEditor.

تقنياً ولحماية البيانات، تقول Sophos إن parsing والتحليل وإنتاج reports يحدث محلياً في browser على endpoint، ولا تُرسل configuration إلى Sophos أو خادم آخر. وهذا مهم لأن Entities.xml قد يحتوي شبكات داخلية وأشياء وقواعد وVPN ومراجع شهادات وأسماء تنظيمية.

لكن المحلي لا يعني الخلو من المخاطر. ما زال browser يحمل التطبيق من الإنترنت. لذلك تبقى أسئلة code version وbrowser cache والعمل offline وحماية endpoint وتخزين exports. ولا ينبغي أن يبقى Entities.xml بلا ضبط في Downloads أو tickets أو cloud sync عادية.

يغطي Config Studio 2.6 خمسة مجالات:

• Configuration Report مع Policy Test وتحليل وبحث شامل؛
• مقارنة إعدادين أو أكثر؛
• Editor مرئي مع Bulk Editing وإخراج XML أو API أو curl؛
• ترحيل Sophos UTM وSonicWall وFortiGate وPalo Alto Networks؛
• توافق Backup Restore وFlexi Port وtransceivers وmodels.

يوسع الإصدار 2.6 هذه المجالات.

دمج templates

تتيح Merge Templates دمج إعدادات baseline مع قوالب قطاعية. يمكن لـ MSP مثلاً جمع إعداد تقني لـ logging وDNS ووصول الإدارة والأشياء القياسية مع template للعيادات أو المدارس أو الفروع.

الفائدة هي إعادة الاستخدام. يمكن أن تشمل baseline وصول الإدارة وNTP وDNS وSyslog وServices ومعايير logging، بينما يضيف template ثانٍ قواعد وأشياء خاصة بالقطاع.

تبقى معالجة التعارضات أساسية:

• ماذا يحدث للأسماء المتطابقة بقيم مختلفة؟
• هل تُحل UUID والمراجع وترتيب القواعد باتساق؟
• أي مراجع interfaces وzones لا تناسب model الهدف؟
• هل ينتج الدمج قواعد مكررة أو متداخلة؟
• هل يستبدل object مقيد بقيمة template أوسع؟

بعد الدمج تصبح Duplicate Analysis وShadow Rule Analysis وUsage References وPolicy Test الكامل إلزامية. نجاح الدمج تقنياً لا يثبت أمان policy الناتجة.

بحث شامل محسن

يعثر البحث الشامل على الأشياء أسرع وينتقل إليها مباشرة. وهذا مهم في القواعد الكبيرة، إذ قد يُستخدم Host object في firewall وNAT وTLS وweb وVPN. يوفر الانتقال المباشر كثيراً من النقرات.

لا يبحث Config Studio في الاسم الظاهر فقط، بل أيضاً في القيم والمسارات والمراجع بحسب نوع البيانات. ويفيد ذلك مع أسماء عامة مثل Server وLAN_Network ومجموعات hosts القديمة.

لكن Search لا يساوي Usage Reference. يجيب الأول: «أين هذا object أو value؟» والثاني: «ما عناصر configuration التي تعتمد عليه؟» يحتاج التغيير الآمن إلى كليهما.

وهذه وظيفة تحتاجها واجهة firewall نفسها بشدة.

تقارير إعداد أوضح

تعرض Reports في قواعد Firewall وNAT وTLS قيم الأشياء وتفاصيلها، لا أسماء المراجع فقط. وبدلاً من Webserver-Gruppe وحدها، يرى reviewer أي hosts أو networks تتضمنها.

هذا تقدم مهم للتدقيق والتسليم ومراجعة أربعة أعين. لا يمكن تقييم قاعدة من دون رؤية المصدر والوجهة وServices والأشياء المرتبطة. فقد يخفي اسم أنيق Any أو شبكة واسعة أو entries منسية.

يدعم report أيضاً Policy Test والتحليل. يحدد Policy Test القاعدة أو Route المطابقة للمصدر والوجهة، ويبحث التحليل عن Shadowing والتكرار. وبما أن SFOS يقيّم قواعد firewall من أعلى إلى أسفل ويتوقف عند أول match، فإن الترتيب جزء من منطق الأمن.

Config Studio 2.6: الترحيل والمقارنة والتصدير

تحليل ترحيل بنسبة نجاح

يعرض Config Studio معلومات الترحيل والتحويل، بما في ذلك النسبة الناجحة. النسبة مؤشر سريع وليست محضر قبول.

تميز Sophos الحالات التالية:

• Supported: ترحيل تلقائي بلا تغيير محتوى؛
• Partial: ترحيل بفجوات يجب إكمالها؛
• Manual: يجب إنشاؤه يدوياً على Sophos Firewall؛
• Not supported: لا يُرحل؛
• Action required: يحتاج قراراً قبل export.

قد تكون الـ5% الناقصة من تحويل 95% هي الشهادات أو كلمات المرور أو VPN أو NAT أو routing خاص. لذلك تأتي القيمة من قائمة ما لم يُرحل وما رُحل جزئياً أو حُل تلقائياً، لا الرقم الأخضر وحده.

اختلاف منطق المصنعين حقيقي. قد تعتمد FortiGate على interfaces أكثر، بينما يستخدم SFOS zones، ولدى Palo Alto نماذج objects وzones وpolicies مختلفة. يحول Config Studio syntax وبنى كثيرة، لكنه لا يثبت بقاء نموذج الأمن مطابقاً دلالياً.

Multi-File Configuration Diff

كانت المقارنة سابقاً تركز على قبل وبعد. يتيح Multi-File Diff رفع إعدادين أو أكثر ومقارنتهما زمنياً. يرتب Config Studio الملفات حسب modification date ويعرض الحقول المضافة والمحذوفة والمعدلة.

تتوفر Side-by-Side وUnified وSemantic. المقارنة Semantic مهمة لأن text diff في XML يمتلئ بضوضاء الترتيب وIDs والتنسيق. ويحاول Entity وField-level diff إظهار التغيير الحقيقي.

يفيد ذلك في إعادة بناء changes والتحقيق. إذا لم تظهر المشكلة بعد نافذة صيانة واحدة مباشرة، يمكن مقارنة exports لمعرفة وقت تغيير rule أو object أو setting.

لكن يلزم حفظ configurations دورياً وtimestamps صحيحة والتعامل الآمن مع exports. تاريخ ملف منسوخ ليس بالضرورة وقت تغيير firewall. ويجب توثيق filename وexport time وhostname وserial number وfirmware وChange Ticket معاً.

من دون version discipline لا يصنع Multi-File Diff تاريخاً. لذلك ستكون الوظيفة أقوى داخل Central مع Audit History غير قابل للتغيير من upload يدوي.

مرجع Backup Restore وFlexi Port والسرعات

يفحص Config Studio توافق Backup Restore ومخطط ports بين models المختلفة. ويعرض Flexi Port modules والسرعات والمعايير حتى 25 أو 40 أو 100 Gbit/s.

يساعد ذلك في hardware migration لتقدير:

• هل يمكن Restore للـ backup؟
• كم physical port متاح؟
• هل Flexi Port modules الحالية متوافقة؟
• ما معايير وسرعات interfaces المدعومة؟

لكنه لا يستبدل تصميم الترحيل. يجب تخطيط LAG وVLAN وBridges وHA وأسماء ports وzones وتعيين interfaces واختبارها بعد Restore.

ينطبق توافق Backup Restore الأوسع على الأهداف ابتداءً من SFOS 20.0 MR2. وقد يظهر Backup Restore Assistant لربط interfaces. يمكن remap للـ physical ports، بينما تتبع VLAN وAliases الـ Parent Interface ويعاد بناء LAG أو Bridges من ports المعينة.

ومع Flexi Ports لا يكفي السؤال هل يركب module. يجب فحص جيل model وform factor وtransceiver والمعيار والسرعة وBreakout وإصدار SFOS معاً. يسرع Config Studio المرجع لكنه لا يستبدل اختبار Link وFailover.

Dark Mode

تذكر Release Notes أيضاً Dark Mode. إنه تحسين استخدام صغير، لا وظيفة firewall. لكنه رمزي: حتى Dark Mode يصل أولاً إلى Config Studio، بينما تتحرك WebAdmin المحلية ببطء بصرياً وعملياً منذ سنوات.

ماذا يخرج Editor تقنياً؟

يستورد Editor الإعدادات أو ينشئها، وينفذ Bulk Changes ويعرض النتيجة كـ Import XML أو API Request أو curl. ويمكن تنزيل XML أو TAR واستيراده عبر Backup & firmware > Import export.

هذه قوة تزيد مسؤولية المسؤول. لا يصبح API Request المولد idempotent تلقائياً، ولا يثبت نجاح Import صحة Rule Order واستخدام objects وNAT وVPN وSecurity Policies. يجب إدراج الإخراج في Change Ticket ومراجعة diff واختبار مسار البيانات فعلياً.

أكثر من 50 إصلاحاً هي السبب الحقيقي لـ MR2

تذكر Sophos أكثر من 50 مشكلة reliability وstability وsecurity أُصلحت. لا تؤثر كلها في كل تثبيت، لكن بعضها خطير تشغيلياً.

أهم المجموعات في رأيي:

HA وFailsafe ليستا موضوعين هامشيين

تؤثر عدة إصلاحات في قابلية appliance للتشغيل:

• NC-181331: كان امتلاء قسم الإعداد يدخل firewall في Failsafe Mode.
• NC-180110: لم يبدأ Logging Daemon على Primary فدخل جهاز HA في Failsafe.
• NC-177441: بعد الترقية إلى v22 GA قد يدخل Primary الأصلي Failsafe بسبب Postgres.
• NC-178906: قد لا يبدأ RED Server Service ويسبب Failsafe.
• NC-177467: لم يبدأ Auxiliary بشكل صحيح عند كثرة اتصالات SSH غير المصادق عليها.

الأسباب مختلفة والأثر واحد: تفقد firewall خدمات أو تدخل وضع حماية أو لا يتوفر شريك HA كما يوحي cluster الأخضر. لذلك لا يكفي HA status: Active-Passive؛ يجب اختبار sync والخدمات وFailover والـ traffic الحقيقي.

إصلاحات IPsec عميقة في مسار البيانات

إصلاحات VPN ليست تجميلية:

• NC-180433: كان Multicast عبر VPN يسبب أعطال firewall متكررة.
• NC-171719: حصل ESP على routing خاطئ في SD-WAN.
• NC-180520: مع IPsec Acceleration بقي XFRM Gateway غير متاح بعد upgrade إذا رُبط tunnel بـ Alias IP ووصل ESP عبر WAN آخر.
• NC-176855: تضرر أداء IPv6 عبر route-based IPsec.
• NC-178121: كان Drag-and-Drop ينقل Site-to-Site IPsec إلى موضع خاطئ في Failover Group.

لا يثبت tunnel Active شيئاً هنا. يجب اختبار XFRM Interface وRouting Table وقرار SD-WAN ومسار ESP وMTU وIPv4 وIPv6 منفصلة، وكذلك ترتيب Failover Groups والتحول بعد الترقية.

كان logging وreporting يسببان الأعطال بأنفسهما

NC-155252 إصلاح مزعج: سببت Disk I/O مرتفعة في reporting ارتفاع CPU وانقطاع الإنترنت حتى دقيقة. أي أن subsystem تحليلياً أثر في مسار الإنتاج.

يصف NC-178745 restart تلقائياً لجهاز HA بسبب Out of Memory في Logging Framework، ويحسن NC-181520 أداء Log Viewer. وهذا يوضح أن Storage وdatabase وGarner وLog Viewer وCentral Reporting مرتبطة بالنظام أكثر مما توحي الواجهة.

بعد MR2 لا يكفي ظهور log lines جديدة، بل يجب التحقق من:

• هل تصل أحداث Firewall وIPS وWAF وAuthentication وVPN كاملة؟
• هل timeline بلا فجوات؟
• هل يستمر Syslog Collector الخارجي بتلقي البيانات؟
• هل CPU وRAM وDisk I/O مستقرة تحت الحمل العادي؟
• هل تتولد Reports من دون التأثير في مسار البيانات؟

تكشف إصلاحات Central حدود “Single Pane of Glass”

مع NC-181175 كانت Group Policies من Sophos Central تبقى Pending. أثرت NC-180513 في Import من Central View بعد MR1، ومنعت NC-181904 تحرير البريد المعزول عبر Central.

المشترك أن الواجهة المركزية قد تقبل task أو تعرضها من دون تنفيذ التغيير فعلياً. بعد Group Policy Push يجب التأكد على الجهاز من object وrule والترتيب وtimestamp. إغلاق dialog بنجاح ليس إثبات commit.

توضح القائمة لماذا لا أقيم Maintenance Releases بطول feature list. إصلاح يجعل logging أو Postgres أو SD-WAN أو Multicast يتوقف عن إدخال firewall في Failsafe أهم من dashboard tile جديدة.

لكن عدد الإصلاحات ليس شهادة جودة تلقائية. إنه يبين الإصلاحات وكذلك عدد الأخطاء الخطيرة السابقة. لذلك لا ينبغي البقاء على build قديمة إلى الأبد ولا نشر MR2 في كل مكان بلا اختبار في اليوم الأول.

ما يجب فحصه قبل الترقية

توصي Sophos بتثبيت MR2 سريعاً لإصلاحات الأمن والاستقرار والأداء. هذا مفهوم، لكن سريعاً في الإنتاج لا يعني بصورة عمياء.

يمنع VLAN tagging القديم على Bridges تثبيت MR2

يضيف MR2 مانع ترقية صارماً عند وجود VLAN tagging قديم عبر CLI على Bridge Interfaces. إذا استُخدم system vlan-tag فلا يمكن الترقية إلى SFOS 22.0 MR2 أو أحدث.

يجب تنظيف هذه الإعدادات أو ترحيلها. كما لا يمكن Restore لنسخ backup التي تتضمنها على SFOS 22.0 GA أو أحدث. وهذا مهم للبيئات القديمة التي عُدلت عبر CLI.

تبقى عوائق v22 السابقة

تستمر متطلبات GA وMR1:

• يجب إزالة Legacy Remote Access IPsec أو ترحيله قبل MR1 أو MR2.
• يحتاج SFOS 22 مساحة أكبر؛ وقد تحتاج appliances desktop أو الافتراضية أو البرمجية إلى تعديل.
• تغير سلوك policy-based IPsec VPN منذ GA ويجب اختباره.
• لا يدعم SFOS 22 أجهزة XG وSG.
• لم تعد RED 15 وRED 15w وRED 50 القديمة مدعومة منذ v21.5.

طريقة ترقيتي

للـ firewalls الإنتاجية سأفعل على الأقل:

1. إنشاء backup حديث وحفظه خارجياً.
2. فحص الدعم والترخيص ومسار upgrade المعتمد.
3. استبعاد Legacy Remote Access IPsec وCLI VLAN tagging على Bridges.
4. فحص تحذيرات Disk Space في Control Center.
5. في HA، فحص العقدتين وsync والـ firmware المتاح.
6. توثيق VPN وWAF وMail Flows وSD-WAN والمصادقة الحرجة.
7. تثبيت MR2 أولاً على test appliance ممثل أو أقل أهمية.
8. اختبار logs وpatterns وHA وrouting وDNS وVPN وWebAdmin وreporting وPolicy Pushes بعد الترقية.

اختبار قبل وبعد مهم جداً مع هذا العدد من الإصلاحات. وإلا نعرف أن firmware جديدة، لا أن مسارات البيانات الحرجة ما زالت تعمل كما ينبغي.

منذ version 20 يملك SFOS ‏Firmware Rollback تلقائياً إذا فشلت configuration migration. يقلل خطر البدء بـ Factory Configuration، لكنه لا يعمل في كل حالة، مثل upgrade path غير المدعوم وبعض workflows لـ Setup Assistant. وبعد rollback يجب تحليل migration.log وmigrationhash.log.

ولا يستبدل rollback نسخة backup خارجية أو Secure Storage Master Key أو console access. إنه يحمي من فشل migration أساساً، ولا يثبت صحة WAF وVPN وHA وreporting بعد نجاح upgrade تقنياً.

في اختباري المباشر سأقيس قبل وبعد:

• restart وبدء الخدمات كاملاً؛
• WebAdmin login واستجابة قوائم القواعد الكبيرة؛
• تدفق logs محلياً وخارجياً؛
• IPsec traffic وRekey وFailover؛
• Central Policy Push مع التحقق على firewall؛
• تحديث patterns لـ IPS وApplication Control؛
• مصادقة STAS جديدة وسلوك Client IP مجهول؛
• HA sync وتغيير دور مضبوط إذا كان النظام cluster.

بعد ذلك فقط يمكنني الحكم. لا يكفي نجاح التثبيت وصفحة Control Center خضراء.

ماذا تقول أولى ملاحظات المجتمع؟

فُتح feedback thread في يوم إصدار MR2 نفسه، ولم تمر عليه سوى ساعات وقت هذا التقييم. لا يمكن الاستنتاج أن MR2 مستقرة أو معيبة.

لكن نقاشين يستحقان الذكر:

• سأل مشغل XGS 5500 في Active-Passive HA عن عمق الاختبارات لأن NC-177467 أزعجته شهوراً في MR1. تسجل Sophos الخطأ كمصلح. وكان يمنع Auxiliary من البدء بسبب عدد هائل من اتصالات SSH غير المصادق عليها.
• يوضح موظف Sophos أن توقيعات PQC معطلة عمداً. ومع زيادة PQC-TLS قد يؤدي تفعيلها إلى رسائل كثيرة. التوصية هي Allow مع logging أولاً ثم الحظر إذا لزم.

هذه مرحلة أولى منطقية: اختبارات فعلية وCase IDs وملاحظات واضحة بدلاً من «يعمل» أو «معطل». وسأراقب thread في الأيام والأسابيع الأولى، خصوصاً HA وIPsec وWAF وSTAS وreporting.

يتحول Config Studio إلى مخزن قطع غيار لواجهة قديمة

والآن الجزء غير المريح.

Config Studio 2.6 أداة جيدة. دمج templates والبحث عن objects وحل المراجع ومقارنة حالات متعددة وإعداد hardware migration وظائف إدارية حقيقية. لا أنتقد بناءها، بل أين تبنيها Sophos.

تذكر Sophos الأداة مباشرة في Firewall Release Notes وإعلان MR2، فتبدو أكثر فأكثر إجابة استراتيجية عن مشكلات يفترض حلها في WebAdmin أو Sophos Central.

تبقى واجهة firewall المحلية قديمة وبطيئة مع الإعدادات الكبيرة. Bulk changes غير كافية. ينقصها استخدام objects والبحث الشامل الحقيقي وdiffs نظيفة وNAT cloning وتعارض القواعد وworkflow تغييرات حديث في المكان الذي يعمل فيه المسؤول يومياً. يسد Central جزءاً فقط من الفجوة.

ليست المشكلة design وحده. تحتاج واجهة firewall حديثة إلى:

• Candidate Configuration بدلاً من تغييرات فردية فورية؛
• diffs كاملة قبل وبعد commit؛
• فحص dependencies بين objects والقواعد وNAT وVPN وTLS؛
• commit ذري أو transaction status واضح؛
• rollback موثوق لآخر حالة معروفة؛
• ربط المستخدم والوقت والمصدر في Audit Trail؛
• Bulk Operations مع preview وفحص تعارض؛
• API output متسق للتغييرات القابلة للتكرار.

يعيد Config Studio بناء أجزاء من ذلك خارج النظام. يحلل export وينشئ XML أو API Requests ويساعد في diffs. لكن تبقى فجوة بين offline view والحالة الفعلية. Sessions وdynamic routing وHA وpatterns والشهادات والإعداد المحمل ليست Entities.xml محلياً.

سيكون مبالغاً استنتاج أن Sophos لن تحدث واجهة SFOS أبداً؛ لا يوجد تصريح مؤكد. لكن الإشارة سيئة: أهم تقدم في الاستخدام والبحث والمقارنة يعود خارج واجهات الإدارة الأساسية.

ويبقى workflow مجزأً:

1. تصدير إعداد firewall.
2. فك archive والبحث عن Entities.xml.
3. رفع الملف إلى أداة browser منفصلة.
4. تحليله أو مقارنته أو تعديله هناك.
5. إعادة export وإدخاله عبر XML أو API أو curl.

هذا مقبول للتدقيق، لكنه التفاف في الإدارة الحديثة والآمنة والقابلة للتتبع. والمزعج أن Config Studio يحصل على Low-Hanging Fruits ينتظرها مسؤولو Sophos منذ سنوات.

وأصبح نقدي أشد: عندما تضع Sophos ‏Config Studio موضوعاً رئيسياً في Firewall Release Notes العادية، لم تعد مجرد أداة إضافية. لقد أصبحت جزءاً واضحاً من استراتيجية الإدارة، وعلى Sophos أن تشرح ما سينتقل إلى WebAdmin أو Central وما سيبقى في browser.

من دون roadmap يظهر أن الواجهة القديمة والبطيئة والأقل سهولة ستبقى، وأن على المسؤول استخدام Config Studio للـ workflows الحديثة. هذه ليست خطة Sophos مؤكدة، لكنها الرسالة الحالية للمنتج.

لماذا تحصل UniFi على فرصة سهلة؟

لا تستبدل UniFi كل Sophos Firewall. تقدم Sophos بحسب الترخيص والبنية وظائف أمن أعمق وIPS وWeb Protection وWAF وEndpoint integration وMDR/XDR ووظائف Enterprise. لا يجوز تجاهل الفروق.

لكن سهولة الاستخدام تفوز يومياً في جودة المنتج المدركة.

تستثمر Ubiquiti بوضوح في design وتطبيقات الهاتف والتنقل المتسق وtopology وسهولة ضم الأجهزة وواجهة مفهومة بلا خبرة طويلة. ليست كل وظيفة UniFi أعمق تقنياً، لكن المنتج يبدو أحدث، وهذا يؤثر في الشراء أكثر مما يعترف المصنعون التقليديون.

لا ترى فرق IT الصغيرة مواصفات IPS فقط، بل تسأل:

• كم بسرعة أجد جهازاً أو قاعدة أو client؟
• هل أفحص البيئة من الهاتف بشكل مفيد؟
• هل أفهم التحذيرات وdependencies بلا خبرة خاصة؟
• كم نقرة يحتاج تغيير يومي؟
• هل المنتج منصة واحدة أم أدوات متجاورة؟

هنا تسهل Sophos الأمر على Ubiquiti بلا داعٍ. قد يوفر Sophos Firewall أمناً أكثر ويظل الأنسب لكثير من بيئات الشركات الصغيرة، لكن فتح Config Studio منفصل للبحث وdiffs وtemplates والتعديل الشامل بينما تبقى الواجهة قديمة وبطيئة يفقد Sophos الثقة في أكثر مستوى مرئي.

لا يحتاج الأمن الجيد محركاً قوياً فقط، بل واجهة يفهم فيها الناس القواعد ويكتشفون الأخطاء وينفذون التغييرات بأمان. سهولة الاستخدام جزء من أمن التشغيل وليست تجميلاً.

الخلاصة: ثبّت MR2، لكن مشكلة المنتج باقية

ليس SFOS 22.0 MR2 ‏Feature Release كبيراً. إنه Maintenance Release مهم بإضافات مفيدة.

يأتي التحكم في PQC في وقته، لكن يجب نشره للمراقبة أولاً. يحسن اكتشاف تطبيقات AI الرؤية وpolicies، لكنه لا يستبدل DLP أو حوكمة AI. يجب نشر إضافة Chromebook Manifest V3 فعلياً. يقلل STAS الانقطاعات لكنه يتطلب فحص قواعد الهوية. تستعد Let’s Encrypt للسلاسل الجديدة. وتعالج الإصلاحات مشكلات سببت أعطال إنتاج حقيقية.

سأثبت MR2 بعد backup وpreflight مباشرة وأختبر مسارات البيانات. لدى المتأثرين بمشكلات HA وVPN وreporting وCentral وFailsafe أسباب جيدة للتحديث. لكن لا يمكن يوم الإصدار معرفة هل النسخة 546 أهدأ أم ستجلب regressions جديدة.

يبقى نقدي واضحاً: Config Studio 2.6 مفيد، لكن ظهوره البارز يعزز الانطباع بأن Sophos تنقل الإدارة الحديثة إلى أداة جانبية. لا يثبت ذلك إلغاء واجهة SFOS جديدة، لكنه تحذير استراتيجي.

لدى Sophos قاعدة firewall قوية، ويجب أن تمنح المسؤولين تجربة إدارة تليق بها. وإلا تفوز المنصات الأحدث لا بأمن أفضل بالضرورة، بل لأنها تحترم الإنسان أمام الشاشة أكثر.

إلى اللقاء،
Joe

الأسئلة الشائعة