Secure Web Gateway الهجرة: قائمة مراجعة لعملية التحويل والرجوع

تعمل عملية الترحيل عبر « secure web gateway » على نقل فحص حركة مرور الويب والسياسات من منصة بروكسي إلى أخرى، سواء كان ذلك من جهاز محلي إلى جهاز جديد، أو إلى خدمة سحابية، أو إلى نموذج هجين. وتغطي قائمة المراجعة هذه التسلسل الكامل للعملية: جرد الموارد، وتصميم الهدف، وترجمة السياسات، والتحضير للرجوع إلى الوضع السابق، والتجربة التجريبية، والاختبار، والتحويل التدريجي، والقبول.

هذه المقالة جزء من دليل أمان السحابة المختلطة. للاطلاع على تفاصيل خاصة بـ « Blue Coat » و«ProxySG» و«Symantec Edge SWG»، انظر «Blue Coat » و«ProxySG End of Life: Migration Planning».

المرحلة الأولى: جرد

تستعرض المرحلة الأولى الوضع الحالي لمجمع البوابة الإلكترونية، وتوجيه حركة المرور، والهوية، وفحص TLS، والسياسات، وعمليات التكامل، وذلك قبل البدء في أي أعمال تصميم.

البنية التحتية

• كل بوابة: الطراز، وإصدار البرنامج، والموقع، والدور، وتواريخ انتهاء العمر التشغيلي (بالنسبة إلى ProxySG و Edge SWG، يرجى الرجوع إلى مقالة «دورة الحياة» الصادرة عن شركة Broadcom)
• حجم حركة المرور وسعة النقل القصوى لكل موقع، مع نسبة فك التشفير باستخدام TLS
• عدد المستخدمين لكل موقع وللوصول عن بُعد
• تسلسل الوكلاء في المراحل الأولية والنهائية، وموازنات الحمل، وتصميم آلية التحويل التلقائي في حالة الفشل

توجيه حركة المرور

• إعدادات الوكيل الصريحة، وملفات PAC، وWPAD
• نقاط اعتراض شفافة (WCCP، التوجيه القائم على السياسات)
• الأنفاق من الفروع (IPsec، GRE)
• الوكلاء على الأجهزة الطرفية
• الاستثناءات المتعلقة بالنشر المباشر على الإنترنت

الهوية

• مجالات المصادقة (SAML، Kerberos/IWA، LDAP، شهادات العميل)
• تعيينات المجموعات المستخدمة في السياسة
• حركة المرور غير المصادق عليها (الخوادم، إنترنت الأشياء، التكنولوجيا التشغيلية) وكيفية التعامل معها

فحص TLS

• تفتيش شهادة الاعتماد (CA)، والموقع الرئيسي، وتاريخ انتهاء الصلاحية، وطريقة التوزيع
• قائمة تجاوزات فك التشفير مع الأسباب وأصحابها

السياسة

• تصدير السياسة بالكامل، بما في ذلك ترتيب القواعد، والفئات، والقوائم المخصصة، والاستثناءات
• القواعد التي لم تُستخدم خلال الـ 90 يوماً الماضية (القواعد المرشحة للإلغاء)

التكامل

• اتصالات ICAP بـ DLP وبرامج مكافحة الفيروسات وبيئات الحماية المعزولة
• إعادة توجيه السجلات إلى نظام SIEM وأدوات إعداد التقارير
• المراقبة والتنبيه

المرحلة الثانية: تصميم الهدف

تحدد المرحلة الثانية الأماكن التي سيتم فيها فحص كل موقع ومجموعة مستخدمين، وكيفية التعامل مع حركة المرور والشهادات والسجلات.

• حدد المكان الذي سيتم فيه فحص كل موقع ومجموعة مستخدمين: في الموقع، أو في السحابة، أو في بيئة مختلطة
• حدد طريقة توجيه حركة المرور لكل من: الوكيل الصريح أو PAC للشبكات المدارة، والوكلاء أو عناصر التحكم في المتصفح للمستخدمين المتنقلين، والأنفاق للفروع
• تأكد من تحديد موقع فحص TLS بحيث يتم فك تشفير كل تدفق مرة واحدة. تنصح إرشادات وكالة الأمن القومي (NSA) بإجراء الفحص مرة واحدة داخل شبكة المؤسسة وتجنب الفحص المتكرر بواسطة الوكلاء المتسلسلين (NSA)
• السعة الاستيعابية لإنتاجية الذروة بعد فك التشفير بالإضافة إلى النمو
• تصميم التوافر العالي وسلوك النظام في حالات الفشل
• تحديد مكان تخزين السجلات وأدلة منع تسرب البيانات (DLP)
• تخطيط إنشاء شهادة التفتيش (CA) الجديدة أو نقل الشهادة الحالية، والتأكد من دعم تخزين المفاتيح وأي تكامل مطلوب مع وحدة إدارة الأمان (HSM)

المرحلة الثالثة: ترجمة السياسات

تقوم المرحلة الثالثة بتحويل السياسة الحالية إلى المنصة الجديدة من خلال عملية مطابقة منظمة ومُثبتة الصحة، بدلاً من التحويل المباشر للملفات.

• قم بمطابقة كل قاعدة مصدر مع نظيرتها الهدف، أو ضع علامة عليها لإلغائها
• تحديد فئات عناوين URL بين الموردين ومراجعة الاختلافات في الفئات ذات التأثير الكبير
• إعادة إنشاء القوائم المخصصة وقوائم السماح وقوائم الحظر
• ترجمة القواعد التي تعتمد على المصادقة والتأكد من تعيينات المجموعات
• إعادة إنشاء طرق التحايل على عملية فك التشفير، ومراجعة كل منها للتأكد من استمرار الحاجة إليها
• استبدال عمليات نقل البيانات الخاصة بنظام منع تسرب البيانات (DLP) القائمة على ICAP بخدمة حماية البيانات الخاصة بالمنصة حيثما أمكن ذلك، مع التأكد من المكان الذي تتم فيه عملية الفحص، أو إعادة إنشاء عمليات التكامل
• سجل كل تغيير وكل قاعدة تم إلغاؤها مع ذكر السبب، وفقًا لعملية مراقبة تغييرات التكوين الخاصة بك (يصف معيار NIST SP 800-128 ممارسات إدارة التكوين التي تركز على الأمن)

تتيح بعض المنصات إمكانية الاستيراد المدعوم للسياسة الحالية. تعامل مع أي عملية استيراد على أنها نقطة انطلاق لا تزال تتطلب المراجعة والاختبار.

المرحلة الرابعة: التحضير لعملية التراجع

تحدد المرحلة الرابعة محفزات التراجع وآلياته قبل بدء المرحلة التجريبية. ويجب اختبار عملية التراجع خلال المرحلة التجريبية والتحقق من الجاهزية قبل كل موجة إنتاج.

مشغلات التراجع (أمثلة)

• حالات فشل المصادقة التي تتجاوز الحد الأقصى المتفق عليه
• توقف تطبيق ذو أهمية حاسمة للأعمال عن العمل لفترة أطول من المدة المتفق عليها
• تذاكر الدعم الفني التي تتجاوز مضاعفًا محددًا من القيمة الأساسية
• تأكد أن الضوابط الأمنية لا تُطبق

آليات التراجع

• استمر في تشغيل البوابات القديمة وتحديثها حتى يتم التسليم النهائي
• احرص على تسجيل التغييرات التي تطرأ على ملف PAC وDNS والتوجيه في إصدارات محددة حتى يمكن التراجع عنها
• أخذ أوقات التخزين المؤقت لنظام أسماء النطاقات (DNS) وملف PAC في الاعتبار عند تقدير مدة التراجع
• تأكد من أن شهادة المصدق (CA) القديمة الخاصة بالفحص تظل موثوقة على الأجهزة خلال فترة الانتقال
• حدد الأشخاص المخولين بالموافقة على التراجع عن التغييرات، وقم بتوثيق الخطوات
• إجراء عملية التراجع التجريبية خلال المرحلة التجريبية والتحقق من الجاهزية قبل كل موجة من عمليات التحويل

المرحلة الخامسة: المرحلة التجريبية

تقوم «المرحلة 5» بتشغيل مجموعة تجريبية تمثيلية على البوابة الجديدة، بالتوازي مع البوابة القديمة، لمدة دورة عمل واحدة على الأقل.

• اختر مستخدمين تجريبيين يمثلون الإدارات الرئيسية وأنواع الأجهزة والمواقع المختلفة، بما في ذلك موظفي تكنولوجيا المعلومات وعدد قليل من المستخدمين المتميزين في مجال الأعمال
• قم بتشغيل البوابة الجديدة بالتوازي مع البوابة القديمة
• توجيه حركة مرور "روت بايلوت" إلى البوابة الجديدة من خلال PAC أو الوكيل أو إجراء تغييرات في التوجيه يمكن التراجع عنها بسرعة
• توفير قناة واضحة للمستخدمين التجريبيين للإبلاغ عن المشكلات
• يجب أن يستمر البرنامج التجريبي لمدة دورة عمل كاملة على الأقل، بما في ذلك نهاية الشهر إن كان ذلك مناسبًا

المرحلة السادسة: الاختبار

تختبر المرحلة السادسة كل مجال سيلاحظ فيه المستخدمون فرقًا، بدءًا من المصادقة وصولاً إلى الأداء والتحويل التلقائي في حالة الفشل.

المرحلة 7: الانتقال التدريجي

تقوم المرحلة 7 بنقل المستخدمين والمواقع إلى البوابة الجديدة على مراحل، بدءًا بالمواقع الأقل عرضة للمخاطر.

• قم بتصنيف المستخدمين والمواقع إلى مجموعات حسب درجة المخاطر والتعقيد، بدءًا بالمواقع منخفضة المخاطر
• أبلغ عن كل موجة مسبقًا، مع ذكر جهة اتصال للدعم
• جدولة الموجات خارج الفترات الحرجة للأعمال
• تعيين طاقم عمل لغرفة العمليات خلال الساعات الأولى من كل موجة
• مراقبة تذاكر خدمة الدعم الفني، ومعدلات الحظر، ومعدلات الأخطاء مقارنةً بالخط الأساسي
• توقف قليلاً بين كل موجة وأخرى لحل المشكلات قبل المضي قدمًا

المرحلة 8: القبول وإيقاف التشغيل

تؤكد المرحلة 8 استيفاء معايير القبول، ثم تقوم بإيقاف تشغيل البوابات والشهادات والعقود القديمة.

معايير القبول (أمثلة)

• تم ترحيل جميع المستخدمين والمواقع
• عاد حجم الطلبات الواردة إلى مكتب الدعم الفني إلى مستواه المعتاد منذ أسبوعين
• تم اجتياز جميع حالات الاختبار في بيئة الإنتاج
• السجلات والتقارير التي تم التحقق منها من قِبل قسم العمليات الأمنية والامتثال
• تمت مراجعة قائمة الاستثناءات والموافقة عليها

إيقاف التشغيل

• إزالة البوابات القديمة من ملفات PAC، وتوجيه الشبكة، ونظام أسماء النطاقات (DNS)
• قم بإلغاء صلاحية شهادة المصدق (CA) القديمة الخاصة بالتفتيش وإزالتها من الأجهزة، في حالة استبدالها
• أرشفة السجلات القديمة وفقًا لسياسة الاحتفاظ بالبيانات
• المسح الآمن للأجهزة والتخلص منها
• إنهاء التراخيص وعقود الدعم

الجدول الزمني النموذجي

تختلف المهل الزمنية حسب حجم التركة ومدى تعقيد وثيقة التأمين.

يمكن لمنظمة ذات موقع واحد إتمام عملية الترحيل في غضون أسابيع. أما المؤسسات الكبيرة ذات المواقع المتعددة، فغالبًا ما تقوم بنشر متوازي واعتماد تدريجي على مدى ستة إلى اثني عشر شهرًا، وفقًا لـ Skyhigh Security.

كيف تدعم Skyhigh عملية الترحيل إلى SWG

تدعم Skyhigh عملية الترحيل إلى SWG من خلال النشر المتوازي، واستيراد سياسات CPL التي تم التحقق من صحتها، ونماذج النشر المرنة.

يتم نشر شبكة Skyhigh Hybrid SSE جنبًا إلى جنب مع البوابات الحالية، بحيث يمكن التحقق من صحة السياسات باستخدام حركة المرور المتوازية قبل أي عملية انتقال. تعيد Skyhigh صياغة سياسة CPL الحالية الخاصة بـ « Blue Coat » في وحدة التحكم الموحدة للسياسات الخاصة بها من خلال عملية استيراد تم التحقق من صحتها، ويتم إنشاء السياسة في وحدة التحكم السحابية الخاصة بـ Skyhigh. يمكن تطبيق سياسات الويب والتطبيقات الخاصة على البوابة المحلية، بينما يتم توجيه حركة المرور التي تتطلب حماية البيانات المطبقة عبر السحابة إلى سحابة Skyhigh. يتم تقديم الخدمة للمستخدمين عن بُعد من خلال نقاط التواجد السحابية. يعمل Skyhigh SWG محليًّا أو في بيئة هجينة أو في السحابة، لذا لا تفرض عملية الترحيل تغييرًا في نموذج النشر. يضيف برنامج تحديث «Blue Coat » دعمًا للخدمات وتعويضًا تجاريًّا للعملاء المؤهلين.

المصادر

1. وكالة الأمن القومي (NSA). إدارة المخاطر الناجمة عن فحص بروتوكول أمان طبقة النقل (TLS) (نوفمبر 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
2. المعهد الوطني للمعايير والتقنية (NIST). SP 800-128: دليل إدارة التكوين لنظم المعلومات مع التركيز على الأمن. https://csrc.nist.gov/pubs/sp/800/128/upd1/final
3. Broadcom. انتهاء الدعم ودورة حياة المنتج لـ Edge SWG (ProxySG) و Advanced Secure Gateway (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html
4. Skyhigh Security. «تحديث نظام « Secure Web Gateway » الخاص بـ Symantec Edge باستخدام شبكة Skyhigh Hybrid SSE Mesh» (15 يوليو 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
5. Skyhigh Security. «أصبح اعتماد النمط الهجين أسهل بفضل منصة Skyhigh SSE» (3 أكتوبر 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html