اختبار تسرب البيانات

اختبار تسرب البيانات\n\nالمصدر المعرفي: اختبار تسرب البيانات في تطبيقات LLM: من حدود الوصول إلى إثبات عدم الكشف

اختبار تسرب البيانات في تطبيقات LLM: من حدود الوصول إلى إثبات عدم الكشف

الخطر الذي ينبغي تعريفه

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

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

رسم حدود الثقة وتدفقات المعلومات

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

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

تعريف قدرات المهاجم وهدفه

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

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

بيانات اختبار مصطنعة قابلة للتعقب

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

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

اختبار الفصل بين المستخدمين والجهات

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

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

اختبار استخدام الأدوات والتصدير

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

يمكن عزل endpoints وهمية وتسجيل body وheaders والمعرفات بدل السماح بخروج بيانات حساسة. ويجب تحليل ما إذا كانت أداة مقيدة بالمستخدم أم تستعمل هوية خدمة واسعة تسمح للوكيل بما لا يسمح به للمستخدم الأصلي. هنا يصبح اختبار حدود السلطة جزءًا أصيلًا من اختبار التسرب.

اختبار التسرب غير المباشر

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

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

حساسية السجلات والتتبع

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

اختبر كذلك ما إذا كان المزود يحتفظ بالمدخلات، ويستخدمها لأغراض تدريب أو تحسين، وأين تقع المعالجة، وأي subprocessors يدخلون المسار. هذه جوانب تعاقدية وتشغيلية يجب التحقق منها بمستندات المورد؛ ولا يمكن استنتاجها من نجاح test prompts فقط.

مقاييس النجاح وحدود الفشل

قسّم النتائج حسب أنواع تدفق البيانات: الاسترجاع غير المصرح، ظهور بيانات في مخرجات المستخدم، تصدير عبر أداة، تسرب جلسات، أو تسرب سجلات. تظهر الأعداد والمقامات وشدة الفشل وصلاحية مستخدم الاختبار، مع فاصل واضح بين attempt وconfirmed breach. قد يحاول المهاجم إخراج بيانات لكنه لا ينجح؛ هذه محاولة محجوبة لا تسرب مؤكد. وقد ينتج النموذج رقمًا مصطنعًا يشبه سرًا لكنه لا يطابق أي canary؛ لا ينبغي تسجيله كاستخراج ناجح دون تحقق.

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

الإجراءات التصحيحية بحسب موضع الخلل

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

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

أثر التغير بعد الإطلاق

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

سيناريو متقدم: مساعد لجنة استثمار

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

النتيجة المطلوبة: سجل حالات يبيّن أي حدود اختبرت، وما وقع فعلًا، وما لم يمكن اختباره. لا ننسب نجاح مؤسسة افتراضية إلى تجربة منشورة من IMDA، ولا نعرضه باعتباره شهادة ضمان.

قائمة الأدلة وقرار الإطلاق

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

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

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

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

تطبيق مصرفي

اختر خدمة مصرفية افتراضية؛ حدد المخاطر والأثر وحدود سلطة النظام والضابط ودليل الاختبار. لا تنسب النتائج إلى بنك واقعي ولا تعد التصنيف الـ42 معيارًا رسميًا.