Zero Trust ليس منتجًا: ابدأ بالموارد والهوية قبل شراء المنصة

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

لهذا يبدأ التطبيق بحصر الموارد والهويات والتدفقات، لا بشراء «منصة Zero Trust». وينص تعريف NIST في SP 800-207 على أن الموقع الشبكي أو ملكية الأصل لا يمنحان ثقة ضمنية، وأن مصادقة الطالب والجهاز وتفويضهما عمليتان تسبقان إنشاء جلسة الوصول إلى المورد.

لماذا لا يساوي Zero Trust أداة VPN أو ZTNA؟

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

الاختبار الحقيقي هو طبيعة قرار الوصول: هل المورد معروف ومصنف؟ هل هوية الإنسان أو الخدمة قابلة للإثبات؟ هل الجهاز مستوفٍ للشروط؟ هل الصلاحية محدودة بالمهمة؟ وهل تستطيع المؤسسة تسجيل القرار وتعديله أو سحب الوصول عندما تتغير الإشارات؟ غياب هذه العناصر يعني أن شراء بوابة جديدة لن يحول البيئة وحده إلى معمارية انعدام ثقة.

المرحلة الأولى: احصر الموارد والهويات والتدفقات

ابدأ بقائمة موارد يمكن إدارتها، لا برسم عام لعناوين الشبكة. سجّل التطبيقات والبيانات والخدمات وواجهات API والأجهزة المهمة، وحدد مالك كل مورد وحساسيته ومكان استضافته واعتماداته. ثم أضف الهويات البشرية وغير البشرية: الموظفين والمتعاقدين وحسابات الخدمة والأجهزة وأحمال العمل السحابية.

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

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

المرحلة الثانية: ثبّت الهوية وحالة الجهاز

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

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

المرحلة الثالثة: حوّل المبادئ إلى سياسة قابلة للاختبار

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

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

المرحلة الرابعة: اختبر مسارًا محدودًا ثم وسّعه

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

لا يلزم استبدال البنية كلها دفعة واحدة. يمكن دمج إدارة الهوية والأجهزة، ونقاط قرار الوصول وإنفاذه، والتقسيم الدقيق، وتجميع السجلات تدريجيًا ما دامت المكونات تتبادل إشارات مفهومة وتطبق سياسة متسقة. ويوثق الدليل النهائي NIST SP 1800-35 بناء 19 تطبيقًا نموذجيًا بالتعاون مع 24 جهة، مستخدمًا أساليب تشمل حوكمة الهوية المحسنة والتقسيم الدقيق وSDP وSASE؛ وهي نماذج قابلة للاقتباس وليست توصية بمنتج واحد.

المرحلة الخامسة: قِس قرارات الوصول قبل تقييم المنصة

اجمع سجلاً يجيب عن أسئلة تشغيلية واضحة: من طلب أي مورد؟ ما الإشارات التي دخلت في القرار؟ ما السياسة التي سمحت أو منعت؟ وهل تغيرت حالة الهوية أو الجهاز خلال الجلسة؟ من دون هذا التسلسل يصعب اكتشاف سياسة فضفاضة أو تفسير رفض مستخدم مشروع.

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

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

اقرأ أيضًا:

• Roman انطلق نحو L2: ثلاثة أشهر قبل أن يبدأ مطاردة الكون المظلم
• تلسكوب Roman يصل إلى صاروخه قبل إطلاق يلاحق المادة المظلمة
• التقييم قبل التمويل أم بعده؟ رقم واحد قد يغيّر حصتك بالكامل