ما هو ZTNA؟ الوصول بمبدأ انعدام الثقة بديلًا عن VPN

ما هو ZTNA؟ الوصول إلى الشبكة بمبدأ انعدام الثقة (Zero Trust Network Access) هو نموذج للوصول عن بُعد يربط المستخدم بالتطبيق الذي يملك صلاحية استخدامه فقط، لا بالشبكة كلها، ويعيد التحقق من الهوية وحالة أمان الجهاز والسياق في كل جلسة. وهو يحل محل نهج الشبكة الافتراضية الخاصة التقليدي القائم على «تحقق مرة واحدة ثم ادخل إلى الشبكة بأكملها».

ما هو ZTNA وماذا يعني مبدأ انعدام الثقة؟

يطبّق ZTNA على الوصول عن بُعد مبدأ «لا ثقة ضمنية في أي مستخدم أو جهاز أو موقع شبكي». يثبت المستخدم هويته أولًا، ثم يخضع الجهاز لفحص حالة الأمان، وبعد ذلك فقط يُفتح اتصال بالتطبيق الوحيد الذي تسمح به السياسة، ولتلك الجلسة فقط. أما بقية الشبكة فتبقى غير مرئية للمستخدم.

انعدام الثقة ليس منتجًا، بل نهج معماري. ويأتي التعريف المرجعي من المعهد الوطني الأمريكي للمعايير والتقنية في منشور NIST SP 800-207 Zero Trust Architecture. ويمكن تبسيط مبادئه الأساسية على النحو الآتي:

• تُعامَل جميع مصادر البيانات وخدمات الحوسبة بوصفها «موارد»؛ ويجب حماية كل شيء من الطابعة إلى خادم تخطيط موارد المؤسسة (ERP).
• تُؤمَّن جميع الاتصالات بغض النظر عن الموقع الشبكي؛ فالطلب القادم من الشبكة الداخلية مشكوك فيه بقدر الطلب القادم من الإنترنت.
• يُمنح الوصول على مستوى الجلسة ووفق مبدأ الحد الأدنى من الصلاحيات.
• يعتمد قرار الوصول على سياسة ديناميكية تقيّم الهوية والتطبيق وحالة الجهاز والإشارات السلوكية معًا.
• تراقب المؤسسة سلامة جميع الأصول التي تملكها أو تستخدمها وحالتها الأمنية.
• يُطبَّق التحقق من الهوية والتفويض بصرامة قبل الوصول ويُعاد عند الحاجة.
• تُستخدم البيانات المجمّعة عن الشبكة والأصول وحركة المرور لتحسين الوضع الأمني باستمرار.

ويصف المستند نفسه بنية منطقية من ثلاثة مكونات: محرك السياسات (Policy Engine) الذي يتخذ قرار الوصول، ومدير السياسات (Policy Administrator) الذي يحوّل القرار إلى أمر بإنشاء الاتصال، ونقطة إنفاذ السياسات (Policy Enforcement Point) التي تفتح المسار بين المستخدم والمورد وتغلقه. وZTNA هو هذه البنية مطبّقة على الموظفين العاملين عن بُعد وبنظام العمل الهجين. فهو يحل المشكلة نفسها التي تحاول الشبكة الافتراضية الخاصة حلها، أي ربط شخص خارج المكتب بتطبيق داخلي بأمان، ولكن بنموذج ثقة مختلف.

لماذا لم تعد الشبكة الافتراضية الخاصة التقليدية كافية؟

الشبكة الافتراضية الخاصة التقليدية للوصول عن بُعد تتحقق من المستخدم مرة واحدة ثم تجعله عضوًا في الشبكة الداخلية؛ فالوصول يُمنح إلى مقطع شبكي لا إلى تطبيق. وهذه الثقة الضمنية تحوّل حسابًا واحدًا مخترقًا إلى نقطة انطلاق للتحرك الجانبي، وتجعل بوابة VPN المكشوفة على الإنترنت هدفًا دائمًا للمهاجمين.

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

• وصول واسع: المستخدم الذي يحتاج إلى برنامج المحاسبة فقط يستطيع في معظم التركيبات رؤية شبكة الخوادم الافتراضية (VLAN) بالكامل بمجرد إنشاء النفق.
• تحقق لمرة واحدة: بعد تسجيل الدخول يبقى النفق مفتوحًا حتى لو أُصيب الجهاز ببرمجية خبيثة أو انتقل المستخدم إلى شبكة أخرى.
• العمى تجاه الجهاز: لا تعرف الشبكة الافتراضية الخاصة التقليدية ما إذا كان برنامج مكافحة الفيروسات يعمل على الجهاز المتصل، أو ما إذا كان نظام التشغيل محدّثًا، أو القرص مشفّرًا.
• سطح مكشوف: بوابة VPN متاحة للجميع بحكم تعريفها؛ وأي ثغرة فيها تعرّض المؤسسة كلها للخطر إلى أن يصدر التصحيح.

وقد غيّر هذا الواقع توجه منتجات Fortinet أيضًا. فوفقًا لـ ملاحظات إصدار Fortinet، أُزيل وضع النفق في SSL VPN اعتبارًا من FortiOS 7.6.3 وحلّ محله IPsec VPN الذي يمكن تشغيله أيضًا عبر منفذ TCP 443؛ ولا تُنقل الإعدادات القديمة عند الترقية. وفي بعض الطرازات المبتدئة بدأت هذه الإزالة في إصدارات أسبق، لذا تحقق من ملاحظات الإصدار الخاصة بطرازك. وقد جمعنا خطوات الانتقال في مقالنا حول إزالة SSL VPN في FortiOS 7.6 وخطة الانتقال، ويظل دليلنا لإعداد VPN على FortiGate نقطة انطلاق جيدة لفهم إعداداتك الحالية.

كيف يعمل ZTNA؟

في ZTNA يعتمد قرار الوصول لا على الموقع الشبكي بل على ثلاثة مدخلات: هوية المستخدم المتحقَّق منها، وحالة أمان الجهاز الطرفي في تلك اللحظة، والتطبيق المطلوب. تُنتج نقطة القرار السياسة، وتفتح نقطة الإنفاذ الاتصال بالتطبيق المستهدف فقط، ولتلك الجلسة فقط، وتغلقه عند تغيّر الظروف.

تتشابه خطوات هذا التدفق لدى معظم المصنّعين:

1. الطلب: يفتح المستخدم تطبيقًا داخليًا، فيعترض وكيل ZTNA على الجهاز الطلب، أو يعترضه وكيل عكسي في حالة الوصول عبر المتصفح.
2. التحقق من الهوية: يُتحقَّق من المستخدم عبر دليل الشركة (Active Directory أو Entra ID أو مزوّد SAML)، والمصادقة متعددة العوامل جزء أساسي من هذه الخطوة.
3. حالة الجهاز: يرسل الوكيل معلومات مثل إصدار نظام التشغيل وحالة مكافحة الفيروسات وتشفير القرص والانضمام إلى النطاق، وتتحول هذه المعلومات إلى وسوم.
4. قرار السياسة: إذا تطابق «مستخدم في مجموعة المالية + جهاز محدّث تديره الشركة + تطبيق ERP» مع قاعدة ما، يُمنح الوصول؛ وإلا يُرفض.
5. الاتصال: تمر حركة المرور عبر بوابة التطبيقات إلى التطبيق المستهدف فقط. لا يُكشف التطبيق مباشرة على الإنترنت، ولا يستطيع المستخدم توجيه حركة المرور إلى بقية الشبكة.
6. التقييم المستمر: إذا تدهورت حالة الجهاز، كأن يُعطَّل برنامج مكافحة الفيروسات، يسقط الوسم وتُنهى الجلسة وفق السياسة.

ولهذا التدفق نتيجتان. الأولى أن التطبيقات تصبح «مظلمة»: فالفحص الخارجي لا يُظهر منفذًا مفتوحًا ولا صفحة تسجيل دخول. والثانية أن ضوابط الأمان ترتبط بالاتصال لا بالشخص؛ فالمستخدم نفسه يصل إلى نظام ERP من حاسوب الشركة المحمول، بينما لا يرى من جهازه اللوحي الشخصي سوى واجهة البريد الإلكتروني. وفي الشبكة الافتراضية الخاصة التقليدية لا يمكن بناء هذا التمييز إلا بمجموعات قواعد معقدة، وغالبًا بشكل منقوص.

مقارنة بين VPN وZTNA

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

يبيّن الجدول أن ZTNA ليس «VPN أفضل» بل نموذج ثقة مختلف. ومع ذلك لم تنتهِ الشبكة الافتراضية الخاصة: ففي أنفاق IPsec بين الفروع، وبعض التطبيقات القديمة المعتمدة على UDP، وسيناريوهات مثل الاتصال الصوتي عبر الإنترنت (VoIP)، يبقى IPsec VPN الأداة الصحيحة. وفي التصميم السليم يتعايش الاثنان لفترة؛ إذ يتولى ZTNA وصول المستخدمين، ويتولى IPsec الربط بين المواقع وحركة المرور الاستثنائية.

بنية Fortinet ZTNA: FortiClient وEMS وبوابة تطبيقات FortiGate

تتكون بنية Fortinet ZTNA من ثلاثة مكونات: وكيل FortiClient ZTNA على الجهاز الطرفي، وFortiClient EMS الذي يحوّل الهوية وحالة الجهاز إلى وسوم، وجهاز FortiGate بوصفه بوابة تطبيقات ZTNA التي تنفّذ قرار الوصول. قُدِّمت هذه البنية مع FortiOS 7.0، وتنطبق ملفات IPS ومكافحة الفيروسات وتصفية الويب الموجودة في FortiGate على حركة ZTNA أيضًا.

يتوزع دور المكونات على النحو الآتي:

وتصف وثائق Fortinet التدفق على النحو الآتي: يتصل FortiGate بـ EMS عبر موصل Security Fabric ويزامن وسوم ZTNA تلقائيًا، وينقل EMS تغييرات الوسوم فورًا عبر اتصال دائم. وتستند وسوم حالة الأمان إلى فحوص مثل: هل برنامج مكافحة الفيروسات مثبّت، وما إصدار نظام التشغيل، وهل سجّل الجهاز الدخول إلى النطاق، وهل تعمل عملية معيّنة، وما قيمة مفتاح معيّن في السجل، وما مستوى ثغرات الجهاز، وهل توجد ثغرة CVE معروفة. ويستطيع FortiGate استخدام هذه الوسوم في قواعد ZTNA وسياسات الجدار الناري وسياسات التحكم في الوصول إلى الشبكة (NAC). وخطوات الإعداد الأساسية موثّقة في دليل إدارة FortiOS من Fortinet.

ويُقدَّم الوصول بشكلين. وكيل الوصول عبر HTTPS ينشر تطبيقات الويب وجلسات RDP وSSH وVNC المغلّفة داخل HTTPS عبر المتصفح أو الوكيل. أما إعادة توجيه TCP فتتيح للتطبيقات غير المعتمدة على الويب بنظام العميل والخادم أن يعترض FortiClient الطلبات الموجهة إلى عناوين ومنافذ محددة ويحيلها إلى بوابة التطبيقات. وبهذا يعمل عميل ERP أو أداة إدارة قواعد البيانات مثلًا دون نفق شبكي. وإذا أردت نقل حركة مرور الفروع والخروج إلى الإنترنت إلى النموذج نفسه، فإن مقالنا حول SASE ونهج FortiSASE هو الامتداد الطبيعي لهذا المقال.

كيف يُخطَّط للانتقال من VPN إلى ZTNA؟

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

1. جرد التطبيقات والمستخدمين: أعدّ قائمة بكل تطبيق يُوصل إليه عبر VPN، وبروتوكوله (HTTPS أو RDP أو SSH أو قاعدة بيانات أو مشاركة ملفات)، ومجموعات المستخدمين. وسجلات VPN هي أصدق مصدر لهذا الجرد.
2. البنية التحتية للهوية: نظافة الدليل، ووضوح بنية المجموعات، والمصادقة متعددة العوامل شروط مسبقة لـ ZTNA. فالحسابات اليتيمة والمجموعات التي يكون الجميع أعضاء فيها تُفرغ أي سياسة من معناها.
3. تجهيز الأجهزة الطرفية: يُثبَّت FortiClient EMS، ويُوزَّع الوكيل أولًا على الأجهزة الحالية، وتُجمع وسوم الحالة في وضع المراقبة. وتعتمد حالة الجهاز على طبقة موثوقة لحماية الأجهزة الطرفية؛ وقد شرحنا الطبقة المطلوبة في مقالنا حول الفروق بين EDR وXDR وMDR.
4. المرحلة التجريبية: ابدأ بتطبيق ويب واحد أو اثنين ومجموعة متطوعة من المستخدمين. تختبر هذه المرحلة منطق السياسات وتجربة المستخدم بمخاطر منخفضة.
5. التوسع: أضف RDP وSSH وتطبيقات العميل والخادم عبر قواعد إعادة توجيه TCP، وأجب لكل تطبيق على حدة عن سؤال «من، وبأي حالة جهاز». ولإبقاء مجموعة القواعد بسيطة تنطبق هنا أيضًا مبادئ إدارة سياسات FortiGate.
6. إدارة الاستثناءات: بالنسبة إلى التطبيقات المعتمدة على UDP أو القديمة التي لا يغطيها ZTNA، احتفظ بـ IPsec VPN بنطاق ضيق.
7. إيقاف بوابة VPN: عند اكتمال تغطية المستخدمين والتطبيقات، عطّل البوابة القديمة واربط سجلات الوصول بنظام الإدارة المركزية للسجلات.

ويصلح هذا الترتيب أيضًا للمؤسسات المضطرة إلى التخلي عن SSL VPN بعد FortiOS 7.6؛ والفرق الوحيد أن الخطوة الأولى تتزامن غالبًا مع جدول ترقية الإصدار.

هل ZTNA واقعي للشركات الصغيرة والمتوسطة؟

ZTNA ليس حكرًا على المؤسسات الكبيرة. فالشركة الصغيرة أو المتوسطة التي تملك جهاز FortiGate تستطيع، بإضافة FortiClient وEMS، تفعيل بوابة تطبيقات ZTNA على الجهاز نفسه. وتتحدد التكلفة بعدد الأجهزة الطرفية، وبما إذا كان EMS سيعمل سحابيًا أو محليًا، وبمدى الحاجة إلى FortiSASE لحركة مرور الفروع؛ ولا يتضح المبلغ إلا في عرض سعر بعد مرحلة الاستكشاف.

تبرز في خبرتنا الميدانية ثلاث حالات يكون فيها ZTNA مجديًا للشركات الصغيرة والمتوسطة. الأولى هي المتعاقدون الخارجيون والمستشارون في المحاسبة أو القانون: فمنحهم VPN يعني فتح الشبكة كلها، أما مع ZTNA فلا يرون إلا التطبيق المعني. والثانية هي التحكم في الوصول إلى البيانات الشخصية: فالحد الأدنى من الصلاحيات وسجلات الوصول التفصيلية يتوافقان مع مصفوفة الصلاحيات وحفظ السجلات الواردة في دليل أمن البيانات الشخصية الصادر عن هيئة حماية البيانات الشخصية التركية (KVKK)؛ وبشرط التحقق من التشريعات السارية والدليل الرسمي، يوفّر ZTNA التطبيق التقني لهذه التدابير. والثالثة هي خطر برمجيات الفدية: فسيناريو دخول المهاجم إلى الشبكة بحساب VPN ووصوله إلى خادم النسخ الاحتياطي يُمنع في ZTNA بحكم التصميم.

ونعمل في Sora Yazılım بوصفنا شريك حلول مستقلًا: نحدد في جلسة الاستكشاف جهاز FortiGate الحالي لديك وملفات المستخدمين وقائمة التطبيقات، ونرسم معًا الحدود بين ZTNA وIPsec، وننفّذ التركيب، ونواصل إن رغبت صيانة السياسات بوصفها خدمة مُدارة.

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

هل يحل ZTNA محل VPN بالكامل؟

نعم فيما يخص وصول المستخدمين إلى التطبيقات عن بُعد؛ إذ يوفّر ZTNA في هذا السيناريو صلاحيات أضيق ورؤية أفضل. أما الربط بين المواقع والتطبيقات القديمة المعتمدة على UDP وبعض سيناريوهات VoIP فيبقى IPsec VPN مناسبًا لها. وفي معظم المؤسسات يعمل الاثنان معًا لفترة.

هل يتطلب ZTNA بالضرورة برنامج وكيل؟

لا. يمكن الوصول إلى تطبيقات الويب دون وكيل عبر المتصفح؛ لكن فحص حالة الجهاز والتطبيقات غير المعتمدة على الويب يتطلبان وكيلًا. وفي بنية Fortinet يكون هذا الوكيل هو FortiClient، وتتحول معلومات الحالة إلى وسوم عبر FortiClient EMS.

هل يحتاج ZTNA على FortiGate إلى ترخيص إضافي؟

بوابة تطبيقات ZTNA ميزة مدمجة في FortiOS. ويلزم ترخيص FortiClient للأجهزة الطرفية وترخيص FortiClient EMS للإدارة المركزية. ولأن نطاق الترخيص يختلف حسب الإصدار والحزمة، ينبغي التحقق منه في وثائق Fortinet الحالية وتحديده بدقة في مرحلة عرض السعر.

ما الفرق بين ZTNA وSASE؟

ZTNA وظيفة واحدة تنظّم وصول المستخدمين الآمن إلى التطبيقات الداخلية. أما SASE فإطار أوسع يجمع ZTNA مع بوابة الويب الآمنة وCASB والجدار الناري كخدمة وSD-WAN ويقدّمها من السحابة. ويقدّم FortiSASE خدمة ZTNA جزءًا من هذا الكل.

كيف يساعد ZTNA في الامتثال لمتطلبات حماية البيانات الشخصية؟

يقيّد ZTNA الوصول إلى التطبيقات التي تحتوي على بيانات شخصية بحسب الهوية والجهاز والتطبيق، ويسجّل كل عملية وصول. ويتوافق ذلك مع مصفوفة الصلاحيات وحفظ السجلات في دليل KVKK لأمن البيانات؛ لكن الامتثال منظومة متكاملة، فتحقق من التشريعات السارية والدليل الرسمي.

هل يتعرض المستخدمون لانقطاع أثناء الانتقال؟

لا إذا خُطط للانتقال جيدًا. ففي المرحلة التجريبية تبقى VPN قيد التشغيل، ويُنقل المستخدمون إلى ZTNA تطبيقًا تلو الآخر، ويمكنهم العودة إلى VPN في اليوم نفسه عند حدوث مشكلة. ويكون خطر الانقطاع أعلى في المشاريع التي يُوزَّع فيها الوكيل على نطاق واسع قبل تجهيز البنية التحتية للهوية.

الخلاصة

يغيّر ZTNA نموذج الثقة في الوصول عن بُعد: التطبيق بدل الشبكة، والتقييم المستمر بدل التحقق لمرة واحدة، والموارد غير المرئية من الخارج بدل البوابة المكشوفة. ويتجسد الإطار الذي رسمه NIST SP 800-207 لدى Fortinet في ثلاثي FortiClient وEMS وبوابة تطبيقات FortiGate، وقد وضعت إزالة وضع النفق في SSL VPN مع FortiOS 7.6.3 هذا الانتقال على جدول أعمال كثير من المؤسسات. والترتيب الصحيح هو: الجرد، ثم الهوية، ثم الأجهزة الطرفية، ثم التجربة، ثم التوسع التدريجي.

لتقييم كيفية نقل بنية VPN الحالية لديك إلى ZTNA معًا، يمكنك طلب جلسة استكشاف مجانية؛ وسنعدّ لك عرضًا يناسب احتياجك من FortiClient وEMS وFortiSASE.