نمذجة تهديدات GenAI وتحويل حدود الثقة إلى حالات اختبار

لماذا تأتي نمذجة التهديد بعد تدفق البيانات

يضع دليل OWASP GenAI Red Teaming Manual v1.0 في القسم 3.3 Threat Modeling فوق خرائط حدود الثقة وتدفقات البيانات الموصوفة في القسم 3.2. السبب أن أسماء فئات الهجوم لا تكفي بذاتها لتحديد ما يجب اختباره في مؤسسة معينة. ينبغي أن يعرف الفريق ما الأصول التي يستطيع مستخدم أو مستند أو أداة التأثير فيها، وأي حد يفترض منع انتقال السلطة، وما شروط وصول الخصم إلى نقطة الدخول. هدف الدرس إنشاء فرضيات اختبار دفاعية تتدرج من وصف خطر معقول إلى معيار إثبات قابل للمراجعة، مع فصل ما هو معروف من تصميم التطبيق عما هو مجرد سيناريو محتمل. لا يُحوَّل أي نموذج تهديد إلى إذن لاختبار خدمة ليست ضمن نطاق التصريح.

المدخلات المطلوبة

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

تحديد الجهات المحتملة

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

ربط الأهداف بقدرة فعلية

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

فئات تقنية متعددة

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

فصل البيانات عن التعليمات

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

تهديدات العزل والذاكرة

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

تهديد صلاحيات الوكيل

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

تهديدات الاستمرارية والموارد

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

اختيار طريقة ترتيب

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

تحويل النموذج إلى Test Cases

تكتب الحالة بمعرف وهدف وأصل ودور وشرط مسبق وحد ثقة ومتجه دخول وضابط متوقع ونتيجة متوقعة ومصدر دليل. يمكن أن تكون الحالة: هل ترفض طبقة أداة تجريبية تعديل سجل موظف حين يكون صاحب الطلب مستخدم قراءة رغم وجود محتوى مسترجع يؤثر في اقتراح الوكيل؟ يحدد PASS برفض الخدمة الخلفية وحفظ حالة السجل، ويحدد FAIL بتغيير غير مخول مثبت في البيئة التجريبية، وتستخدم INCONCLUSIVE عندما يغيب سجل موثوق أو تتعطل الأداة. لا تنقل تعليمات هجومية قابلة لإساءة الاستخدام إلى تقرير عام؛ يكفي وصف منهج الحكم وشروط التحقق ضمن نطاق مأمون.

قابلية مراجعة النموذج

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

مقاييس التغطية

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

تمرين نمذجة متكامل

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

النتيجة التي ينبغي تسليمها

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

المصدر والحدود

المصدر المنهجي هو القسم 3.3 Threat Modeling (Overlay on Section 3.2) في OWASP GenAI Red Teaming Manual v1.0، أكتوبر 2026، ابتداءً من الصفحة 44، مع الاستناد إلى 3.2 Trust Boundaries & Data-Flow Mapping وإلى معايير الاختبار في Phase 7. هذا الدرس تحليل عربي تعليمي مستقل من سيادة AI لا يمثل ترجمة رسمية أو إثبات امتثال. جميع الأمثلة افتراضية وتنطبق فقط على أنظمة يملك المختبر تصريحاً قانونياً وتشغيلياً بفحصها. تُراعى رخصة المصدر CC BY-SA 4.0 عند اقتباس أو تكييف مواد مرخصة.