الفحص المحلي للفصل TLS مقابل الفحص السحابي: المفاضلات المتعلقة بالنشر

التفتيش عبر بروتوكول TLS (الذي لا يزال يُطلق عليه غالبًا اسم التفتيش عبر بروتوكول SSL) هو عملية اعتراض جلسة TLS، وفك تشفيرها باستخدام شهادة موثوقة من المؤسسة، وفحص المحتوى، وإعادة تشفيره قبل إعادة توجيهه إلى الوجهة المقصودة. وبدون هذه العملية، لا ترى بوابات الويب الآمنة ومحركات منع تسرب البيانات (DLP) وبيئات الاختبار (sandboxes) سوى البيانات الوصفية للوجهة. أما مع هذه العملية، فيمكنها اكتشاف البرامج الضارة، ومنع تسرب البيانات، وفرض سياسات الاستخدام المقبول داخل الجلسات المشفرة.

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

هذه المقالة جزء من دليل أمن السحابة الهجينة.

كيفية عمل فحص TLS

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

يعمل الوكيل كخادم بالنسبة للعميل وكعميل بالنسبة للوجهة:

1. يبدأ العميل جلسة TLS مع موقع ويب أو تطبيق.
2. يقوم الخادم الوكيل باعتراض الاتصال وتقديم شهادة للوجهة، موقعة من قبل هيئة إصدار الشهادات (CA) الخاصة بالمؤسسة والتي تثق بها أجهزة العملاء.
3. يقوم الوكيل بفتح جلسة TLS خاصة به مع الوجهة الحقيقية، ويتحقق من صحة شهادة ذلك الخادم.
4. يتم فك تشفير حركة المرور بين الجلستين، وفحصها، ثم إعادة تشفيرها.

وهذا يعني أن الوكيل يمتلك مفتاحًا قويًا للغاية ويتعامل مع النص العادي لكل جلسة يتم فحصها. ويوصي التوجيه الصادر عن وكالة الأمن القومي (NSA) بعنوان «إدارة المخاطر الناجمة عن فحص بروتوكول أمان طبقة النقل (TLS)» بالحد من حدوث ذلك إلى أدنى حد ممكن: إجراء الفحص مرة واحدة فقط، داخل شبكة المؤسسة، وتجنب الفحص المكرر من قبل عدة وكلاء إعادة توجيه. وقد حذرت CISA في تنبيهها السابق بشأن اعتراض HTTPS من أن منتجات الفحص التي يتم تنفيذها بشكل سيئ يمكن أن تضعف أمان TLS، على سبيل المثال من خلال الفشل في التحقق من صحة الشهادات المنبع بشكل صحيح.

نظرة عامة على الفحص المحلي للفحص مقابل الفحص السحابي لبروتوكول TLS

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

تستخدم معظم المؤسسات الهجينة كلا الخيارين: الفحص المحلي لحركة المرور المحددة في الموقع والخاضعة للتنظيم، والفحص السحابي للمستخدمين عن بُعد. قم بتوزيع إنهاء TLS عبر كل مسار وتجنب فك التشفير الزائد، بما في ذلك عندما تقوم البوابة المحلية بإعادة توجيه حركة المرور للخدمات التي تُطبق عبر السحابة.

مسارات فك التشفير

يجب أن يحدد كل تصميم هجين كل نقطة إنهاء وإعادة تشفير في بروتوكول TLS، مع تجنب عمليات الفحص الزائدة عن الحاجة.

تشمل المسارات الشائعة ما يلي:

• اتصال مستخدم Office بالإنترنت: عبر بوابة محلية، أو عبر نفق إلى نقطة تواجد سحابية
• المستخدم البعيد المتصل بالإنترنت: نقطة وجود سحابية، أو توصيل عبر شبكة خلفية إلى بوابة محلية
• من المستخدم إلى التطبيق الخاص: تحديد ما إذا كان مسار ZTNA المحدد يدعم فحص TLS وأين يتم ذلك
• جلسة المتصفح: عناصر تحكم على مستوى المتصفح تتيح عرض المحتوى دون فك التشفير عبر الشبكة
• نقطة النهاية: الفحص القائم على الوكيل على الجهاز

يتمثل أحد المخاطر في البيئات الهجينة في حدوث عملية فك تشفير مكررة غير مخطط لها. فقد يقوم أحد الفروع بإرسال حركة المرور عبر وكيل محلي، ثم عبر خدمة سحابية تقوم بإنهاء اتصال TLS مرة أخرى. يجب توثيق كل مرحلة فحص مطلوبة، وحماية كل حدود للنص العادي، وإزالة المراحل الزائدة التي تزيد من التعرض للمخاطر أو تعقيد عملية استكشاف الأخطاء وإصلاحها.

مسؤوليات الشهادة

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

• فحص إنشاء شهادة المصادقة (CA) وحمايتها. قم بتوثيق مكان تخزين المفتاح الخاص، ومن يمكنه الوصول إليه، وما إذا كان استخدام وحدة أمان الأجهزة (HSM) مطلوبًا أم لا. تأكد من عمليات تكامل وحدات HSM المدعومة لكل بوابة محلية أو خدمة سحابية وإصدار المنتج الخاص بها؛ ولا تفترض أن الدعم متوفر.
• التوزيع. كيفية تثبيت شهادة CA في مخازن الثقة الخاصة بنظام التشغيل والمتصفح على الأجهزة الخاضعة للإدارة، وما يحدث على الأجهزة غير الخاضعة للإدارة.
• التناوب. الجدول الزمني وإجراءات استبدال وحدة التفتيش (CA) دون توقف التشغيل.
• التحقق المسبق. تأكد من أن الوكيل يرفض شهادات الوجهة غير الصالحة أو منتهية الصلاحية أو الملغاة، بدلاً من إخفائها عن المستخدمين.
• دعم البروتوكولات. يجب فحص TLS 1.3 (RFC 8446) بشكل أصلي، دون الرجوع إلى إصدار أقدم.

الاستثناءات المتعلقة بحركة المرور

لا ينبغي لأي مؤسسة أن تقوم بفك تشفير كل شيء، لذا يجب الاحتفاظ بقائمة استثناءات موثقة وتخضع للمراجعة بانتظام:

قم بمراجعة الاستثناءات كل ثلاثة أشهر. فالتجاوزات القديمة تمثل نقطة عمياء شائعة.

رسالة «Client Hello» المشفرة وما الذي تغيره

يعمل بروتوكول «Client Hello» المشفر على إخفاء اسم مضيف الوجهة عن المراقبين السلبيين، لذا فإن الرؤية القائمة على SNI وبعض قرارات التحايل تحتاج إلى إعادة النظر.

نُشرت بروتوكول «Client Hello» المشفر (ECH) باعتباره RFC 9849 في عام 2026. يعمل بروتوكول ECH على تشفير الجزء من عملية المصافحة في بروتوكول TLS الذي كان يكشف سابقًا عن اسم مضيف الوجهة (مؤشر اسم الخادم) وحقول أخرى. وتفقد الأدوات السلبية التي تصنف حركة المرور من خلال قراءة مؤشر اسم الخادم (SNI) القدرة على رؤية هذه المعلومات في المواقع التي تدعم بروتوكول ECH.

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

• قد ترسل المتصفحات ملحقات شبيهة بـ ECH حتى في حالة عدم استخدام ECH، لذا يتعين على منتجات الفحص التعامل معها بشكل صحيح.
• تشير وثيقة طلب التعليقات (RFC) إلى أنه في بيئات المؤسسات الخاضعة للإدارة، تتمثل إحدى الطرق في تعطيل ميزة ECH من خلال سياسة المجموعة والاعتماد على التزام العملاء بهذا الإعداد.
• تحتاج القرارات المتعلقة بالفئات والسمعة التي كانت تعتمد على SNI بالنسبة لحركة المرور التي تم تجاوزها إلى بديل، مثل ضوابط طبقة DNS أو التكوين الصريح للوكيل.

تأكد من خطة العمل الخاصة بـ ECH التي يتبعها مزود خدمات الفحص الخاص بك، واختبر أداءها مع الإصدارات الحالية من المتصفحات.

تسجيل

قد تحتوي سجلات الفحص على عناوين URL وهويات وأدلة تتعلق بمنع تسرب البيانات (DLP)، لذا فإن محتواها وموقعها والوصول إليها تتطلب قرارات صريحة:

• ما هي الحقول التي يتم تسجيلها بالنسبة لحركة المرور التي تم فك تشفيرها مقابل تلك التي تم تجاوزها؟
• أين يتم تخزين السجلات، وما إذا كان يجوز نقلها خارج نطاق الولاية القضائية
• فترات الاحتفاظ، ومن يمكنه الوصول إلى الأدلة الكاملة للمحتوى
• ما هي الأحداث التي يتم إعادة توجيهها إلى نظام SIEM؟

تسهّل عمليات التفتيش المحلية الاحتفاظ بالسجلات والأدلة داخل البلد. أما عمليات التفتيش على السحابة فتتطلب التأكد من مناطق تخزين السجلات الخاصة بالمزود وضوابط الوصول. انظر «سيادة البيانات» في «أمن السحابة المختلطة».

المفاضلات التشغيلية

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

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

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

يجمع الفحص الهجين بين الاثنين، لكنه لا يعمل بشكل جيد إلا مع محرك سياسات واحد. فإذا كانت البوابات المحلية والسحابية تحتوي على قوائم استثناءات وقواعد لمنع تسرب البيانات (DLP) منفصلة، فسيتم التعامل مع المستخدمين بشكل مختلف حسب الموقع.

كيف تتعامل شركة «سكايهاي» مع عمليات التفتيش المحلية وعبر السحابة

تقوم Skyhigh بفحص TLS محليًّا حيثما يتطلب ذلك الامتثال، وفي السحابة بالنسبة للمستخدمين عن بُعد، وذلك في إطار سياسة واحدة.

تقوم شبكة Skyhigh Hybrid SSE Mesh بفك تشفير SSL/TLS وفحصه محليًّا على الأجهزة الخاصة بالمؤسسة حيثما يتطلب الامتثال ذلك، وفي نقاط التواجد السحابية لـ Skyhigh للمستخدمين عن بُعد، مع محرك سياسات واحد يشمل كلا النظامين. يتم تطبيق سياسة « Secure Web Gateway » و«Zero Trust Access» بشكل أصلي على البوابة، بينما تُطبق سياسة حماية البيانات في سحابة Skyhigh على حركة المرور التي تعيد توجيهها البوابة. يتم فحص حركة مرور الويب التي تم فك تشفيرها على البوابة المحلية وإعادة تشفيرها هناك من أجل تطبيق سياسة الويب المحلية. وعندما تستخدم سياسة ما خدمة مطبقة عبر السحابة مثل حماية البيانات، تقوم البوابة بإعادة توجيه حركة المرور ذات الصلة إلى سحابة Skyhigh، حيث يتم تطبيق نفس السياسة. تضيف عناصر التحكم الآمنة في المتصفح بدون وكيل (Agentless Secure Browser Controls) فحصًا يدعم WebSocket لحركة مرور الذكاء الاصطناعي والرسائل في جلسة المتصفح.

المصادر

1. وكالة الأمن القومي (NSA). إدارة المخاطر الناجمة عن فحص بروتوكول أمان طبقة النقل (TLS) (نوفمبر 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
2. وكالة الأمن السيبراني والبنية التحتية (CISA). «اعتراض HTTPS يضعف أمان بروتوكول TLS» (تنبيه TA17-075A، مارس 2017). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
3. IETF. RFC 8446: بروتوكول أمان طبقة النقل (TLS) الإصدار 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
4. IETF. RFC 9849: رسالة «Client Hello» المشفرة بواسطة TLS. https://www.rfc-editor.org/rfc/rfc9849.html
5. IETF. RFC 9000: QUIC: بروتوكول نقل آمن ومتعدد الإرسال قائم على بروتوكول UDP. https://www.rfc-editor.org/rfc/rfc9000.html
6. Skyhigh Security. «أصبح اعتماد النمط الهجين أسهل بفضل منصة Skyhigh SSE» (3 أكتوبر 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
7. 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