معالجة نتائج Red Teaming وإعادة الاختبار وتوثيق إغلاق المخاطر

التفريق بين العثور على ضعف وإغلاقه

تنتهي تجربة الفريق الأحمر باكتشاف سلوك لا يطابق الضابط الأمني المتوقع، لكن هذا لا يعني انتهاء مسؤولية المؤسسة عند كتابة التقرير. فثمة فرق بين مشاهدة خرق لحد الثقة وإثبات السبب الجذري، وبين تغيير تكوين أو شفرة وإثبات أن التغيير أغلق المسار. يركز هذا الدرس على مرحلة Post-Engagement & Remediation من دليل OWASP GenAI Red Teaming Manual v1.0 في أكتوبر 2026، ويربطها بمعايير التقييم التي تسبقها. الهدف إنشاء دورة تتبع تضمن ألا تتحول نتائج الاختبارات إلى قائمة ملاحظات تتقادم، أو إلى أرقام مغلقة دون برهان. لا يعد الدرس ترجمة رسمية للمصدر، ولا يمثل وصفاً لسياسة إلزامية واحدة لكل مؤسسة. كل مثال هنا يتعلق بأنظمة مصرح بفحصها وبيانات اصطناعية، وتحتاج القرارات الفعلية موافقة أصحاب الصلاحية.

سجل الضعف وإثبات الحالة الأصلية

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

من السلوك إلى السبب الجذري

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

تحديد الملكية وسلطة قبول المخاطر

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

أولوية الإصلاح لا تعتمد على الانطباع

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

اختيار الضابط في الطبقة الصحيحة

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

الاحتواء المؤقت والقرار التشغيلي

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

فحص المعالجة قبل اختبار الانحدار

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

معيار إعادة اختبار محدد مسبقاً

يُشتق معيار إعادة الاختبار من فشل الحالة الأصلية، ثم تضاف حالات مجاورة تضمن عدم وجود تجاوز واضح من المسار نفسه. في وكيل يستطيع إعداد طلب شراء ولا يجوز له اعتماده، يجب إثبات أن طلب اعتماد دون تفويض يُرفض في نظام الأعمال الخلفي، وأن سجلات الرفض تظهر الهوية والسياق المناسبين، وأن الطلب المشروع من صاحب الصلاحية ما زال يعمل. هذا أفضل من الاكتفاء بأن الوكيل أجاب «لن أنفذ». إذا كانت الحالة الأصلية متعلقة بفهرس RAG، تتحقق المراجعة من أن البحث نفسه لا يعيد مستندات مستأجر آخر، وليس فقط أن النموذج يمتنع عن تلخيصها. ينبغي تسجيل PASS وFAIL وINCONCLUSIVE وفق أدلة قابلة لإعادة القراءة.

التعامل مع اختلاف السلوك التوليدي

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

تجربة الانحدار والسلوك المشروع

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

توجيه الفريق الأزرق

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

أثر التغيير لدى الموردين

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

سلسلة الأدلة القابلة للتدقيق

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

التقرير التنفيذي وإعادة فتح القرار

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

نشاط تطبيقي

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

المصدر وحدود التفسير

المصدر المنهجي الأساسي OWASP GenAI Security Project, GenAI Red Teaming Manual, Version 1.0, October 2026، وخصوصاً مرحلة Post-Engagement & Remediation المرتبطة بتكامل الفريق الأحمر والأزرق والمعالجة والتحسين المستمر، مع الاستفادة من مرحلة التقييم والتقارير السابقة. هذا الدرس توسعة تعليمية عربية من سيادة AI وليس نصاً رسمياً صادراً عن OWASP ولا يمثل شهادة مطابقة. الوثيقة الأصلية تعلن رخصة CC BY-SA 4.0؛ ينبغي نسبة المصدر وشروط الأعمال المشتقة عند استخدامها، والرخصة على https://creativecommons.org/licenses/by-sa/4.0/legalcode. يجب إجراء أي اختبار على أنظمة مصرح بها، ولا يثبت إغلاق حالة في بيئة واحدة غياب جميع المخاطر أو الامتثال التنظيمي في جميع القطاعات.