اختيار وضع الاختبار ومحاكاة الخصم في الأنظمة التوليدية

اختيار وضع الاختبار ومحاكاة الخصم في الأنظمة التوليدية

الغرض من المحاكاة

يعلّم هذا الدرس اختيار نوع الخصم والاختبار المناسب قبل الخلط بين تقييم النموذج وفحص التطبيق واختبار استجابة الفريق الأزرق. يشرح دليل OWASP GenAI Red Teaming Manual v1.0 في صفحته السابعة أن Black-Box وGray-Box وWhite-Box تعكس مقدار الوصول الذي يفترض أن يملكه الخصم أو المختبر، وأن المهمة قد تستخدم واحداً منها أو أكثر بحسب الأهداف. ولا يمكن معرفة سبب الإخفاق الداخلي من رد لغوي واحد في واجهة المحادثة، كما لا يجوز التعامل مع قدرة حصل عليها المختبر عبر صلاحية مميزة وكأنها متاحة لكل مهاجم خارجي. لذلك يرتبط تصميم المحاكاة أولاً بسلسلة بيانات وأصول وعمليات وبالغرض الذي يسعى مالك النظام إلى التحقق منه.

حالة شركة خدمات مالية

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

النموذج الخارجي للصندوق الأسود

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

الفحص الجزئي بالصندوق الرمادي

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

الفحص الداخلي بالصندوق الأبيض

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

اختيار نوع المهاجم

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

التمييز بين القدرة والرغبة والنتيجة

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

مصفوفة أدوار وسلطات

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

ربط الخطر بالتهديدات المعروفة

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

علاقة النمط بهدف الاختبار

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

إدارة فرضيات الاستطلاع

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

معايير نجاح متنوعة

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

التوثيق وإعادة الإنتاج

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

تمرين تطبيقي

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

الأخطاء في النموذج المقترح

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

الإسناد

يعتمد الدرس على AI Red Teaming Posture في الصفحة السابعة وWhen to Use an AI Red Team Exercise في الصفحات 8–9 وPhase 1 Planning & Scoping في الصفحات 14–25 وPhase 2 Reconnaissance في الصفحات 26–30 من دليل OWASP GenAI Red Teaming Manual v1.0 أكتوبر 2026. هذا المحتوى بناء تعليمي مستقل من سيادة وليس ترجمة رسمية ولا تصنيفاً إلزامياً للمؤسسات. تستخدم الأمثلة أنظمة وبيانات افتراضية بهدف بيان الدليل ومنهج الحكم. يُحترم ترخيص CC BY-SA 4.0 للمصدر الأصلي عند إعادة استخدام مادته، ولا يمنح الشرح حق ممارسة نشاط ضد أنظمة دون تفويض.