إنتقل إلى المحتوى الرئيسي

كيف يعمل الوصول إلى الشبكات وفق مبدأ انعدام الثقة؟

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

الفكرة الأساسية مباشرة:

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

لذلك ليس ZTNA بروتوكولًا واحدًا أو بنية منتج واحدة أو نموذج نشر واحدًا؛ إذ تختلف تطبيقات المورّدين له.

تسلسل قرار ZTNA​

يمكن تصوير نموذج منطقي مفيد كما يلي:

تسلسل قرار ZTNA المنطقي من المستخدم أو عبء العمل عبر التحقق من الهوية وإشارات الجهاز والسياق وقرار السياسة والإنفاذ والمورد المصرح به وإعادة التقييم والتدقيق

تختلف التفاصيل بحسب المنتج، لكن هذه المسؤوليات تمثل النمط الأساسي لـ ZTNA.

1. تحديد هوية طالب الوصول​

قبل التفويض بالوصول، يحتاج النظام إلى معرفة مَن أو ما الذي يطلبه.

بالنسبة للمستخدم البشري قد تأتي الهوية من:

  • موفّر هوية OIDC.
  • دليل مؤسسي.
  • سجلات هوية محلية.
  • أنظمة مصادقة أخرى.

الهوية ليست التفويض. ولا ينبغي للنجاح في إثبات هوية المستخدم أن يمنحه كل الموارد الخاصة تلقائيًا.

2. تحديد الجهاز​

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

قد يتتبع نظام ZTNA الجهاز بصورة منفصلة عن المستخدم عبر:

  • تسجيل الأجهزة.
  • الشهادات أو مفاتيح الأجهزة.
  • معرّفات الأجهزة المُدارة.
  • إشارات MDM.
  • إشارات EDR.
  • فحوص نظام التشغيل أو الحالة الأمنية.

ينتج عن ذلك قرار سياسة يميز مثلًا بين حاسوب شركة مسجّل وجهاز مجهول يخص المستخدم نفسه.

3. جمع السياق​

تظل الهوية والجهاز مهمين، لكن يمكن أن تضم السياسة سياقًا إضافيًا:

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

لا يحتاج المنتج كل إشارة ممكنة ليصنف ZTNA؛ فالمهم أن يكون الوصول صريحًا ومحكومًا بالسياسة لا ممنوحًا تلقائيًا لمجرد الوجود «داخل» الشبكة.

4. اتخاذ قرار السياسة​

يجيب محرّك السياسة عن سؤال مثل:

هل يُسمح لهذا المستخدم، على هذا الجهاز، بالوصول إلى هذا المورد في الظروف الحالية؟

ينبغي أن يكون القرار ضيقًا بما يكفي للتعبير عن علاقة الوصول المقصودة مباشرةً.

مثلًا:

  • المطورون ← خوادم التطوير.
  • قسم المالية ← تطبيق المحاسبة.
  • المورّد ← بوابة صيانة واحدة حتى يوم الجمعة.
  • المسؤول ← لوحة الإنتاج بعد الموافقة فقط.

وهذا يختلف عن إدخال الجهاز إلى الشبكة ثم الاعتماد على ضوابط لاحقة لتقييد الوصول.

5. إنفاذ القرار​

يتطلب ZTNA نقطة إنفاذ بين طالب الوصول والمورد.

تشمل النماذج الشائعة:

عميل وبوابة أو موصّل​

ينشئ عميل على الجهاز اتصالًا آمنًا عبر بوابة أو موصّل أو مكوّن إنفاذ مشابه.

يناسب هذا النموذج البروتوكولات التي تحتاج إلى اتصال على مستوى الشبكة.

وكيل دون عميل​

بالنسبة إلى تطبيقات المتصفح، يمكن لوكيل HTTP/HTTPS مصادقة المستخدم وتفويضه دون تثبيت برنامج نفق على الجهاز.

ويصبح الوكيل نقطة الإنفاذ بين المتصفح والتطبيق المحمي.

شبكة متمحورة حول النظراء​

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

كلها مناهج معمارية صالحة إذا بقي الوصول إلى المورد مصرّحًا به صراحةً.

6. حصر نطاق الوصول​

الغرض من ZTNA ليس التشفير وحده.

يحمي النقل المشفر الحركة أثناء انتقالها؛ لكن ZTNA يجيب أيضًا عن الموارد التي يجوز لطالب الوصول المصادق عليه بلوغها.

قد تقلل سياسات الموارد الضيقة الانكشاف غير الضروري والحركة الجانبية مقارنةً بمنح اتصال شبكي واسع.

ولا يلغي ذلك الحاجة إلى تقسيم الشبكة أو ضوابط المضيف؛ فهي وسائل دفاع إضافية مفيدة.

7. إعادة تقييم الوصول​

قد تتغير الشروط بعد بدء الوصول:

  • انتهاء نافذة زمنية مؤقتة.
  • تعطيل حساب.
  • فقد الجهاز لحالة أمنية مقبولة.
  • تغيّر الدور أو المجموعة.
  • إلغاء مسؤول للموافقة.

ينبغي أن تتمكن بنية ZTNA من الاستجابة لتغييرات السياسة ذات الصلة بدلًا من افتراض استمرار صلاحية الاتصال الأول إلى الأبد.

8. تسجيل ما حدث​

قرارات الوصول أحداث أمنية أيضًا.

يمكن أن تشمل السجلات المفيدة:

  • الهوية.
  • الجهاز.
  • المورد المطلوب.
  • حدث المصادقة.
  • نتيجة السياسة.
  • وقت الوصول.
  • الإلغاء أو الرفض.

تدعم هذه السجلات التحقيق ومراجعات الوصول وتشخيص المشاكل وتكامل SIEM.

ZTNA ليس MFA فقط​

تقوّي المصادقة متعددة العوامل إثبات الهوية، لكنها لا تحدد وحدها تفويض الوصول إلى الموارد.

قد ينجح مستخدم في MFA ويظل غير مخوّل لتطبيق بعينه.

يجمع ZTNA المصادقة بسياسة الموارد والسياق الآخر.

ZTNA ليس مجرد بروتوكول VPN​

قد توفر WireGuard وIPsec وTLS نقلًا آمنًا في بنى مختلفة.

لكن النفق الآمن لا يعرف دور الموظف أو امتثال الجهاز أو الموافقة لمدة 30 دقيقة أو كون التطبيق المطلوب خارج سياسة المستخدم.

تلك اهتمامات تفويض تتولاها منظومة الوصول المحيطة.

كيف يرتبط WireGuard بـ ZTNA؟

مستوى التحكم مقابل مستوى البيانات​

يساعد فهم الفرق عند مقارنة منتجات ZTNA.

مستوى التحكم​

يتولى عادةً مسؤوليات مثل:

  • التهيئة.
  • الهويات والمجموعات.
  • تعريف الموارد.
  • السياسات.
  • تنسيق المفاتيح أو التصريحات.
  • الإجراءات الإدارية.

مستوى البيانات​

يحمل مستوى البيانات حركة التطبيقات الفعلية أو يتوسط نقلها.

يشغّل بعض المورّدين المستويين سحابيًا. ويشغّل آخرون مستوى التحكم سحابيًا بينما ينشر العميل موصّلات. وتسمح منتجات أخرى بالاستضافة الذاتية للمنصة كاملة أو التشغيل دون سحابة للمورّد.

لا تكشف كلمة «ZTNA» وحدها نموذج المنتج المستخدم.

قارن ZTNA المستضاف ذاتيًا والسحابي

نماذج نشر ZTNA الشائعة​

مقدم سحابيًا​

يشغّل المورّد خدمة التحكم ويوفر غالبًا بنية إنفاذ موزّعة عالميًا.

مستوى تحكم لدى المورّد مع موصّلات لدى العميل​

يشغّل المورّد خدمات السياسة والتنسيق، وينشر العميل موصّلات أو بوابات قرب التطبيقات الخاصة.

مستضاف ذاتيًا​

يشغّل العميل أو مزوّد الخدمات المُدارة البنية الأساسية للإدارة والإنفاذ.

مستقل أو غير متصل​

يمكن لنظام الوصول الاستمرار دون خدمة تحكم إلزامية يستضيفها المورّد، وقد يُنشر بصورة دائمة داخل بيئة معزولة.

لكل نموذج مفاضلات مختلفة في التشغيل والتوافر والتحكم بالبيانات والاعتماد على الإنترنت.

أين يقع ZTXGate؟​

يستخدم ZTXGate منصة وصول يديرها العميل أو مزوّد الخدمات المُدارة.

يستخدم مساره المُدار WireGuard للنقل، بينما يستطيع الوصول المرخّص دون عميل تمرير تطبيقات HTTP/HTTPS المدعومة. وتسهم الهوية والجهاز والمورد والحالة الأمنية والوقت والموافقة ومتطلبات المصادقة الإضافية في السياسة.

يمكنه العمل مستقلًا دون مستوى تحكم سحابي إلزامي لدى CoreZT، بما في ذلك البيئات المعزولة. ويمكن للنشر المتصل استخدام ZTXHub الاختياري الذي تديره CoreZT لإدارة التراخيص والتحديثات مركزيًا.

استكشف بنية ZTXGate · استكشف ZTXGate

مزيد من القراءة​

أدلة ذات صلة وخطوات تالية​