ما هي بنية انعدام الثقة Zero Trust؟ دليل مبسط للأمن السيبراني
لم تعد حدود المؤسسة محصورة داخل مبنى أو شبكة داخلية واحدة. يعمل الموظفون من المنزل، وتُخزن البيانات في خدمات سحابية، وتتصل الأنظمة بمورّدين وأجهزة شخصية وتطبيقات خارجية.
لذلك لم يعد من المنطقي اعتبار كل جهاز داخل الشبكة موثوقًا لمجرد أنه اتصل بشبكة الشركة. هنا تظهر بنية انعدام الثقة (Zero Trust Architecture)، وهي نهج أمني يرفض منح الثقة تلقائيًا بناءً على الموقع أو ملكية الجهاز، ويجعل الوصول إلى كل مورد مرتبطًا بالهوية والسياق والسياسات.
لا تعني Zero Trust أن المؤسسة تشك في كل موظف أو تعيد تسجيل الدخول كل ثانية، كما أنها ليست منتجًا واحدًا تشتريه ثم تنتهي المهمة.
إنها طريقة لتصميم الوصول وحماية الموارد، تجمع بين التحقق من المستخدم والجهاز، وأقل قدر من الصلاحيات، والمراقبة المستمرة، والاستجابة للمخاطر. يوضح هذا الدليل المفهوم كما تصفه مواصفة NIST SP 800-207، ثم يحوله إلى خطوات عملية يمكن للمؤسسات البدء بها.
ما المقصود ببنية انعدام الثقة؟
Zero Trust هو نموذج أمني يركز على حماية الموارد نفسها، مثل التطبيقات والبيانات والخدمات والحسابات، بدل الاعتماد على حدود الشبكة وحدها.
تنص إرشادات NIST على عدم منح ثقة ضمنية لمستخدم أو جهاز لمجرد وجوده داخل شبكة محلية أو امتلاكه من المؤسسة. ويجب أن تكون المصادقة والتفويض وظيفتين واضحتين قبل إنشاء جلسة الوصول إلى المورد.
مصطلح «انعدام الثقة» لا يعني انعدام الثقة البشرية أو منع التعاون؛ بل يعني عدم افتراض أن الطلب آمن دون أدلة وسياسة مناسبة. فالموظف الشرعي قد يستخدم جهازًا مصابًا، وقد تُسرق بيانات اعتماد حساب صحيح، وقد يتعرض جهاز داخل المكتب لاختراق. لذلك يقيّم النظام هوية الطالب وحالة الجهاز ونوع المورد والسياق والمخاطر قبل منح الصلاحية.
من الأفضل التعامل مع Zero Trust بوصفها رحلة نضج أمني. قد تبدأ المؤسسة بحماية البريد والحسابات الإدارية، ثم تتوسع إلى التطبيقات السحابية والبيانات والأجهزة والشبكات الداخلية. ويجب أن تتناسب الإجراءات مع قيمة المورد والمخاطر، بدل تطبيق سياسة موحدة معقدة على كل طلب.
لماذا لم يعد نموذج المحيط التقليدي كافيًا؟
كان النموذج التقليدي يبني دفاعًا قويًا حول شبكة داخلية، ويستخدم جدارًا ناريًا أو بوابة VPN للسماح للمستخدمين بالدخول. بعد اجتياز البوابة، يحصل المستخدم أحيانًا على وصول واسع إلى موارد كثيرة.
لكن هذا النموذج يفترض ضمنيًا أن الداخل أكثر موثوقية من الخارج، وقد يصبح هذا الافتراض خطيرًا عند سرقة حساب أو اختراق جهاز متصل.
تتوزع التطبيقات اليوم بين مراكز البيانات والسحابة والهواتف والأجهزة المحمولة، وقد يتصل المستخدم من شبكة عامة أو منزلية.
كما يمكن أن تتواصل الخدمات بعضها مع بعض عبر واجهات برمجية وحسابات آلية. لذلك لا تكفي معرفة أن الاتصال جاء من عنوان IP داخلي؛ بل يجب التحقق من هوية المستخدم أو الخدمة والجهاز والصلاحية المطلوبة.
لا يعني ذلك أن جدران الحماية أو VPN أصبحت بلا فائدة. تظل هذه الأدوات مهمة لتأمين الاتصال وتقليل سطح الهجوم، لكنها لا تكفي وحدها لإثبات أن كل طلب مسموح. يمكن دمجها ضمن بنية Zero Trust عندما تكون جزءًا من سياسة أوسع لحماية الموارد.
المبادئ الأساسية في Zero Trust
1. التحقق الصريح من الهوية والسياق
ينبغي التحقق من هوية المستخدم أو الخدمة باستخدام وسائل مناسبة لحساسية المورد، ثم تقييم سياق الطلب. قد يشمل السياق موقع الاتصال التقريبي، ووقت الوصول، وحساسية البيانات، وسلوك الحساب، وحالة الجهاز، ومستوى المخاطر. ولا ينبغي اعتبار أي إشارة منفردة دليلًا كاملًا على الثقة؛ فالموقع الجغرافي مثلًا قد يكون مفيدًا لكنه يمكن تزويره أو تغييره.
2. أقل قدر من الصلاحيات
يمنح المستخدم الحد الأدنى من الصلاحيات اللازمة لإنجاز مهمته، ولفترة مناسبة، وعلى الموارد التي يحتاج إليها فقط. لا يحتاج موظف التسويق إلى صلاحية إدارة خوادم الإنتاج، ولا ينبغي أن يحتفظ حساب مؤقت بصلاحية دائمة. ويقلل هذا المبدأ أثر اختراق الحساب؛ لأن المهاجم لا يحصل تلقائيًا على كل موارد المؤسسة.
3. افتراض إمكانية الاختراق
تُصمم الأنظمة على أساس احتمال تعرض حساب أو جهاز أو خدمة للاختراق. لذلك تُراقب الجلسات والسجلات، وتُقسّم الموارد، وتُحدد مسارات الوصول، وتُجهز المؤسسة لإلغاء الجلسة أو تقييدها عند ظهور مؤشرات خطر. لا يعني ذلك إيقاف كل نشاط عند أول تنبيه، بل استخدام قواعد واضحة للاستجابة بحسب درجة الخطورة.
4. تقييم مستمر بقدر مناسب للمخاطر
قد تتغير حالة الجهاز أو سلوك الحساب بعد بدء الجلسة. لذلك يمكن إعادة تقييم بعض الإشارات أثناء الجلسة أو عند طلب مورد حساس. على سبيل المثال، قد يسمح النظام بالاطلاع على ملف عام ثم يطلب مصادقة أقوى قبل تنزيل بيانات مالية. ويجب تصميم إعادة التقييم بطريقة لا تعطل العمل دون داعٍ.
المكونات المنطقية لبنية Zero Trust
تصف NIST مجموعة مكونات منطقية تساعد على فهم طريقة اتخاذ قرار الوصول. من أهمها محرك السياسات الذي يحدد ما إذا كان الطلب مسموحًا وفق القواعد والمعلومات المتاحة، ونقطة إدارة السياسات التي تنشئ الجلسة أو تنهيها، ونقطة إنفاذ السياسات التي تتحكم فعليًا في مرور الطلب إلى المورد.
تتصل هذه المكونات بمصادر معلومات مثل مزود الهوية، وإدارة الأجهزة، ومخزون الأصول، وسجلات النشاط، وأنظمة كشف التهديدات، وقواعد بيانات الصلاحيات. وقد تتوزع هذه الوظائف على منتجات متعددة أو خدمات سحابية، لكن المهم أن تكون القرارات متناسقة وقابلة للتدقيق. لا يشترط أن تكون جميع المكونات في جهاز واحد أو من شركة واحدة.
كيف تعمل عملية الوصول في مثال عملي؟
لنفترض أن موظفًا يعمل عن بُعد يريد فتح نظام الموارد البشرية. يبدأ الطلب بتحديد هوية الموظف عبر مزود الهوية، ثم يتحقق النظام من وسيلة المصادقة ومستوى الحماية المطلوب.
بعد ذلك يفحص حالة الحاسوب: هل هو مسجل في إدارة الأجهزة؟ هل نظامه محدث؟ هل توجد مؤشرات اختراق؟ ثم يقارن هذه المعلومات بسياسة الوصول إلى تطبيق الموارد البشرية.
إذا استوفت الإشارات الشروط، يمنح النظام جلسة محدودة تسمح للموظف بالوصول إلى الوظائف المناسبة لدوره. وإذا حاول الموظف فتح نظام مالي حساس، فقد تتطلب السياسة مصادقة أقوى أو جهازًا مُدارًا أو موافقة إضافية. وإذا ظهرت إشارة خطر أثناء الجلسة، يمكن تقليل الصلاحيات أو إنهاء الجلسة أو طلب تحقق جديد.
هذا المثال يوضح أن القرار لا يعتمد على سؤال واحد مثل «هل المستخدم داخل شبكة الشركة؟». بل يجمع بين الهوية والجهاز والمورد والسياق والسياسة، ويمنح الوصول المطلوب فقط.
كما أن المستخدم لا يحتاج بالضرورة إلى إعادة إدخال كلمة المرور في كل نقرة؛ يمكن استخدام رموز جلسات قصيرة العمر وآليات تحقق مناسبة لتقليل الاحتكاك مع الحفاظ على الحماية.
خطوات عملية لتطبيق Zero Trust في مؤسسة
- حصر الموارد والبيانات: أنشئ قائمة بالتطبيقات والأنظمة والبيانات الحساسة، وحدد مالك كل مورد وقيمته ومخاطر الوصول إليه.
- بناء هوية مركزية: اربط الحسابات بمزود هوية موثوق، وأوقف الحسابات غير المستخدمة، وفعّل المصادقة متعددة العوامل للحسابات المهمة.
- جرد الأجهزة وإدارتها: ميّز الأجهزة المؤسسية عن الشخصية، وافحص التحديثات والتشفير والحماية وحالة الامتثال قبل السماح بالوصول إلى الموارد الحساسة.
- تقسيم الصلاحيات: راجع الأدوار، وأزل الصلاحيات الزائدة، واستخدم حسابات إدارية منفصلة ومؤقتة للمهام عالية الحساسية.
- تطبيق سياسات حسب المورد: ابدأ بالتطبيقات الأكثر حساسية، وحدد الشروط المطلوبة لكل نوع وصول بدل فتح الشبكة كاملة بعد تسجيل الدخول.
- جمع السجلات ومراقبة المخاطر: اجمع سجلات الهوية والأجهزة والتطبيقات، واربط التنبيهات بخطة استجابة محددة.
- الاختبار والتحسين: جرّب السياسات على مجموعة صغيرة، وراقب حالات الرفض الخاطئة وتأثيرها في العمل، ثم وسّع التطبيق تدريجيًا.
ما دور المصادقة متعددة العوامل وإدارة الأجهزة؟
تقلل المصادقة متعددة العوامل احتمال نجاح المهاجم الذي حصل على كلمة المرور وحدها، لكنها ليست حلًا كاملًا إذا كانت طريقة المصادقة ضعيفة أو يمكن خداع المستخدم.
ينبغي اختيار وسائل مقاومة للتصيد للحسابات الحساسة متى أمكن، وإدارة دورة حياة وسائل المصادقة، ومراجعة الأجهزة المسجلة وإلغاء الأجهزة المفقودة أو غير المستخدمة.
أما إدارة الأجهزة فتساعد على معرفة ما إذا كان الحاسوب أو الهاتف يلتزم بمتطلبات المؤسسة. يمكن أن تشمل هذه المتطلبات تشفير القرص، وتحديث النظام، وقفل الشاشة، والحماية من البرمجيات الخبيثة، وإدارة التطبيقات. ولا يعني الجهاز المُدار أنه آمن بشكل مطلق؛ بل يوفر إشارات إضافية تدخل في قرار الوصول.
توضح إرشادات NIST SP 800-63-4 متطلبات الهوية الرقمية والمصادقة وإدارة وسائل التحقق، وهي مرجع مفيد عند تصميم جزء الهوية في البنية. كما يمكنك قراءة مفهوم صلاحية الوصول لفهم مبدأ التفويض، وتصنيف البيانات لتحديد مستوى الحماية المناسب.
مقاييس تساعد على تقييم نجاح التطبيق
لا يُقاس نجاح Zero Trust بعدد المنتجات المشتراة أو عدد مرات طلب المصادقة. من المقاييس المفيدة نسبة التطبيقات الحساسة التي تستخدم هوية مركزية، وعدد الحسابات ذات الصلاحيات الإدارية الدائمة، ومدة إلغاء صلاحية حساب عند مغادرة موظف، ونسبة الأجهزة المطابقة للسياسات، وعدد محاولات الوصول غير المصرح بها التي تم إيقافها.
يمكن أيضًا قياس زمن منح الوصول المشروع، ومعدل الرفض الخاطئ، ووقت اكتشاف الحساب المخترق واحتوائه، وعدد الموارد التي ما زالت تعتمد على ثقة الشبكة الداخلية وحدها. يجب تفسير هذه المؤشرات معًا؛ فخفض زمن الوصول مهم، لكنه لا ينبغي أن يتحقق عبر إضعاف ضوابط الحماية.
أخطاء شائعة عند تطبيق Zero Trust
- اعتبارها منتجًا جاهزًا: شراء بوابة أو منصة لا يحقق النموذج دون جرد الموارد والسياسات والهوية وإدارة الأجهزة.
- إضافة خطوات تحقق بلا تحليل: تكرار المصادقة دون ربطها بالمخاطر يزعج المستخدمين ولا يضمن حماية أفضل.
- تجاهل الحسابات الآلية: حسابات الخدمات وواجهات API تحتاج إلى هويات وصلاحيات ومفاتيح مُدارة مثل المستخدمين.
- منح صلاحيات واسعة بعد التحقق: نجاح المصادقة لا يعني أن المستخدم يحتاج إلى كل موارد الشبكة.
- إهمال السجلات والاستجابة: جمع التنبيهات دون مالك أو خطة معالجة يترك المخاطر دون احتواء.
- تطبيق شامل دفعة واحدة: قد يؤدي ذلك إلى تعطيل الخدمات؛ الأفضل البدء بالموارد الأعلى خطورة ثم التوسع.
هل تلغي Zero Trust الحاجة إلى VPN وجدران الحماية؟
لا. يمكن استخدام VPN لحماية النقل أو ربط المواقع، ويمكن لجدران الحماية تقليل الاتصالات غير المرغوبة. لكنهما لا يثبتان وحدهما أن المستخدم مخول للوصول إلى تطبيق بعينه. في بنية Zero Trust يمكن أن تبقى هذه الأدوات ضمن طبقات الحماية، مع إضافة قرارات وصول دقيقة مرتبطة بالهوية والجهاز والمورد.
وبالمثل، لا تلغي Zero Trust النسخ الاحتياطي أو التحديثات أو التوعية أو حماية البريد. إنها إطار يربط هذه الإجراءات ضمن استراتيجية تركز على الموارد وتقليل الثقة الافتراضية. وتساعد ضوابط مكافحة البرمجيات الخبيثة والتصيد في تقليل احتمال وصول مهاجم إلى بيانات اعتماد صحيحة.
أسئلة شائعة حول Zero Trust
هل تعني Zero Trust عدم الثقة بالموظفين؟
لا. المقصود عدم منح صلاحية تقنية تلقائية اعتمادًا على الموقع أو الملكية، بل التحقق من الهوية والسياق وتطبيق سياسة وصول مناسبة.
هل يمكن تطبيق Zero Trust في شركة صغيرة؟
نعم، يمكن البدء بإدارة الهوية والمصادقة متعددة العوامل وتقليل الصلاحيات وجرد الأجهزة، ثم التوسع حسب الموارد والمخاطر والميزانية.
هل تحتاج المؤسسة إلى السحابة لتطبيق Zero Trust؟
لا. يمكن تطبيق المبادئ في بيئات محلية أو سحابية أو هجينة؛ فالنموذج يركز على حماية الموارد وليس على موقع استضافتها.
هل تضمن Zero Trust منع الاختراق؟
لا يوجد نموذج يضمن منع جميع الهجمات، لكنها تقلل الثقة الافتراضية وتحد من الحركة الجانبية وأثر الحسابات المخترقة عند تنفيذها ومراقبتها جيدًا.
الخلاصة
تساعد بنية Zero Trust المؤسسات على الانتقال من الاعتماد على حدود الشبكة إلى قرارات وصول مبنية على الهوية والجهاز والسياق وحساسية المورد. يبدأ التطبيق الفعال بجرد الأصول، وتقوية الهوية، وتقليل الصلاحيات، وإدارة الأجهزة، ثم توسيع السياسات والمراقبة تدريجيًا. وهي ليست منتجًا واحدًا ولا بديلًا عن بقية الضوابط، بل طريقة متكاملة لتصميم الوصول وحماية الموارد.
المصادر والمراجع
[1] NIST – Zero Trust Architecture
