طوّر مورّد متخصص في الذكاء الاصطناعي نموذجًا خاصًا لفهم اللغة الطبيعية تفوّق بفارق كبير على النماذج المنافسة في حالة الاستخدام المستهدفة لديه، وهي تحليل العقود القانونية. وقد طُوّر النموذج على مدى ثلاث سنوات، ودُرّب على مجموعة نصوص خاصة كبيرة من المستندات القانونية الموسومة، وصُقل عبر تعاون مكثف مع مختصين قانونيين. وكان النموذج يمثل الحصن التنافسي الأساسي للمورّد. وأتاح المورّد النموذج عبر API مؤمّنة جيدًا: مصادقة TLS متبادلة، وإدارة مفاتيح API بنطاقات دقيقة، وتحديد المعدل، وكشف الشذوذ في أحجام الاستعلام غير المعتادة. وكانت المعمارية الأمنية حقيقية ومطبقة جيدًا. ودمج عملاء المورّد الأربعون من المؤسسات النموذج في منتجاتهم للتقنية القانونية، مثل أدوات مراجعة المستندات ومنصات إدارة العقود وتطبيقات البحث القانوني. وأنشأ كل تكامل مسارًا من نموذج المورّد عبر تطبيق العميل المؤسسي. وحدد مهاجم يستهدف نموذج المورّد أن أحد العملاء الأربعين، وهو شركة ناشئة ذات موارد أمنية محدودة، قد نفّذ تكامل API بحد أدنى من الضوابط الأمنية: إذ كان مفتاح API مضمّنًا مباشرة في الشيفرة المصدرية للتطبيق، التي كان جزء منها مرئيًا في مستودع على GitHub. فحصل المهاجم على مفتاح API من مستودع GitHub واستخدمه للاستعلام المنهجي من API النموذج لدى المورّد على مدى ثلاثين يومًا، فأجرى أربعمئة ألف استعلام في مجال تحليل العقود القانونية. ونبّه كشف الشذوذ لدى المورّد إلى حجم الاستعلام غير المعتاد في اليوم الثامن والعشرين. وبحلول ذلك الوقت، كان المهاجم قد جمع من أزواج الاستعلام والاستجابة ما يكفي لتدريب نموذج بديل يقارب قدرات المورّد في تحليل العقود. لقد أمّن المورّد نموذجه، لكن النموذج سُرق عبر تكامل غير آمن لدى أحد العملاء.
ما حقيقة مخاطر سرقة النماذج؟
مخاطر سرقة النماذج هي خطر أن يتمكن مهاجم من إعادة بناء منطق القرار وقدرات نموذج ذكاء اصطناعي خاص عبر الاستعلام المنهجي من API الخاصة بالنموذج، إما مباشرة أو عبر طرف ثالث لديه وصول مشروع إلى API، دون أن يصل المهاجم قط إلى أوزان النموذج أو معماريته أو بيانات تدريبه. وتختلف سرقة النماذج عن استخراج النماذج من حيث الدافع: فالاستخراج يكون عادةً لأغراض الاستخبارات التنافسية أو الميزة التنافسية، بينما تصف السرقة فعل الاستيلاء على قدرات النموذج دون تصريح. والاثنان متشابهان تقنيًا، إذ يستخدم كلاهما الاستعلام المنهجي من API لتدريب نموذج بديل، لكن آثارهما القانونية قد تختلف.
مشكلة سطح الهجوم الممتد هي بُعد سلسلة التوريد. فمورّد الذكاء الاصطناعي الذي يتيح نموذجه لعملاء المؤسسات عبر API ينشئ سطح هجوم ممتدًا: فكل عميل مؤسسي يدمج API ينشئ مسارًا إلى النموذج. قد يكون أمن API لدى المورّد نفسه ممتازًا. لكن العميل المؤسسي الذي ينفّذ التكامل بمفتاح API مضمّن في الشيفرة، أو بإدارة غير كافية لبيانات الاعتماد، أو بضوابط وصول قاصرة، ينشئ مسارًا ضعيف التأمين إلى نموذج المورّد. ولا يحتاج المهاجم الذي يستهدف النموذج إلى اختراق أمن المورّد؛ بل يكفيه أن يجد أقل تكاملات العملاء المؤسسيين أمانًا ويستغله.
يحدد بُعد جودة النموذج البديل عواقب السرقة. فالنماذج البسيطة ذات المخرجات المحدودة التعقيد، مثل المصنّفات الثنائية ونماذج الانحدار ذات الخصائص القليلة، يمكن محاكاتها بعدد قليل نسبيًا من الاستعلامات. أما النماذج المعقدة ذات المخرجات الغنية، مثل النماذج اللغوية الكبيرة والمصنّفات متعددة الفئات ذات المخرجات التفصيلية والنماذج التي تعطي درجات ثقة دقيقة، فتتطلب استعلامات أكثر، لكن يظل من الممكن محاكاتها إلى حد كبير إذا توفر الوقت وحجم الاستعلامات الكافيان. وتتوقف قيمة النموذج المسروق على جودة النموذج البديل؛ فالنموذج البديل عالي الجودة الذي يقارب قدرات النموذج الأصلي في حالة الاستخدام المستهدفة هو في الواقع الميزة التنافسية للنموذج الأصلي وقد انتقلت إلى المهاجم.
يمثل بُعد الملكية الفكرية الإطار القانوني لسرقة النماذج. فقد تكون نماذج الذكاء الاصطناعي الخاصة قابلة للحماية بوصفها أسرارًا تجارية، إذ قد تُعد معمارية النموذج المحددة ومنهجية التدريب والأوزان المدرَّبة معلومات من الأسرار التجارية. وقد تُعد سرقة النموذج عبر الاستعلام من API، باستخدام مخرجات النموذج لتدريب نموذج بديل، استيلاءً غير مشروع على أسرار تجارية حتى عندما يكون الوصول إلى API الذي أتاحها قد تم الحصول عليه بوسائل مشروعة (كما عندما يستخدم المهاجم مفتاح API مسروقًا من أحد العملاء المؤسسيين). ولا يزال الإطار القانوني لسرقة نماذج الذكاء الاصطناعي في طور التشكل، لكن إطار الأسرار التجارية ينطبق بشكل متزايد.
لماذا يهم هذا
تكتسب سرقة النماذج أهميتها في TPRM من اتجاهين. الأول: إذا نشرت المؤسسة نموذجًا خاصًا لمورّد وسُرق هذا النموذج عبر تكامل غير آمن لدى المؤسسة، فقد تكون المؤسسة مسؤولة عن السرقة بوصفها مصدر مفتاح API المسرّب. والثاني: إذا طوّرت المؤسسة نماذج ذكاء اصطناعي خاصة تشاركها مع شركاء أو عملاء، فإن كل نقطة تكامل تمثل سطحًا لمخاطر سرقة النماذج يجب أن يخضع للحوكمة.
أين تخطئ معظم الفرق
الإخفاق الأكثر تكرارًا هو تقييم أمن النموذج على مستوى API لدى المورّد دون تقييم أمن تنفيذ التكامل لدى المؤسسة نفسها. فأمن نموذج المورّد لا يتجاوز قوة أضعف تكامل يُوصل إليه من خلاله.
- تقييم أمن API لدى المورّد دون تقييم أمن تكاملات المؤسسات
- عدم تقييم إدارة مفاتيح API في تطبيق المؤسسة
- عدم مراعاة سطح API الممتد عبر تكاملات العملاء
- عدم تقييم إمكانية بناء نموذج بديل للنموذج المُتاح
- الإطار القانوني لسرقة النماذج: عدم تقييم حماية الأسرار التجارية
كيف تبدو الممارسة الجيدة
تطبق البرامج الناضجة لمنع سرقة النماذج أفضل ممارسات إدارة مفاتيح API في جميع تكاملات النماذج، فلا بيانات اعتماد مضمّنة في الشيفرة، مع تدوير المفاتيح وقصر نطاقها على الحد الأدنى اللازم من نقاط النهاية، إلى جانب مراقبة حجم الاستعلامات على مستوى التكامل لرصد الاستعلام المنهجي المتسق مع محاولات الاستخراج.
- إدارة مفاتيح API في التكامل: عدم تضمينها في الشيفرة، وتدويرها، وأدنى نطاق ممكن
- مراقبة حجم الاستعلامات لكل مفتاح API: خط الأساس وكشف الحالات الشاذة
- رصد الاستخراج من جهة المورّد: نمذجة تهديد النموذج البديل
- متطلبات أمن التكامل: المورّد يشترط ضوابط أمنية على عملائه من المؤسسات
- إطار حماية الأسرار التجارية للنماذج المملوكة
الأدوات
أمن API: تحديد معدل الطلبات في بوابة API، وكشف الحالات الشاذة لكل مفتاح، وفحص بيانات الاعتماد في CI/CD
ترصد أدوات فحص بيانات الاعتماد، مثل ميزة فحص الأسرار في GitHub وGitleaks وTruffelhog، مفاتيح API وبيانات الاعتماد المُودَعة عن طريق الخطأ في مستودعات الشيفرة المصدرية. وبالنسبة إلى ممارسي TPRM الذين يسألون المورّد: هل تشترطون فحص بيانات الاعتماد في مسارات التطوير لدى عملائكم من المؤسسات شرطًا للوصول إلى API؟ فإن هذا السؤال يكشف ما إذا كان المورّد يحمي نفسه من سطح الهجوم الممتد الذي تُنشئه تكاملات عملائه.
تحديات الحوكمة
يتمثل تحدي الحوكمة في سرقة النماذج عبر تكاملات العملاء في محدودية سيطرة المورّد على أمن التنفيذ لدى عملائه من المؤسسات. إذ يستطيع المورّد أن يشترط ضوابط أمنية تعاقديًا، لكن إنفاذها صعب. ويكمن حل الحوكمة في الإنفاذ التقني على مستوى API: تحديد نطاق مفاتيح API بما يقيّد حجم الاستعلامات والوصول إلى نقاط النهاية، وكشف الحالات الشاذة الذي يرصد أنماط الاستعلام المتسقة مع الاستخراج بصرف النظر عن مفتاح API المستخدم.
- اشتراط أفضل ممارسات إدارة مفاتيح API في عقود التكامل
- طبّق مراقبة حجم الاستعلامات لكل مفتاح لرصد الاستخراج
- أجرِ فحص بيانات الاعتماد في مسار CI/CD بحثًا عن مفاتيح API النموذج
- قيّم إمكانية بناء نموذج بديل للنماذج الخاصة
- أدرج ضمانات الحماية من سرقة النماذج في شروط خدمة API
إذا كنت فريقًا صغيرًا
لأي نموذج تتيحه عبر API، سواء للموردين أو للعملاء، طبّق ضابطين. أولًا، دقّق جميع تطبيقات التكامل بحثًا عن مفاتيح API مضمّنة في الشيفرة، واستخدم أداة فحص بيانات الاعتماد على جميع مستودعات الشيفرة التي تنفّذ التكامل. ثانيًا، طبّق مراقبة حجم الاستعلامات لكل مفتاح API مع تنبيهات بالحالات الشاذة، بحيث ينبغي أن يؤدي أي مفتاح يتجاوز حدًّا معينًا من الاستعلامات المنهجية إلى فتح تحقيق. يعالج هذان الضابطان أكثر مسارات سرقة النماذج شيوعًا: كشف بيانات الاعتماد والاستخراج القائم على الحجم.
- دقّق كل شيفرة التكامل بحثًا عن مفاتيح API مضمّنة فيها باستخدام أداة لفحص بيانات الاعتماد
- طبّق مراقبة حجم الاستعلامات لكل مفتاح API مع تنبيهات الشذوذ
- دوّر فورًا أي مفاتيح API يُعثر عليها في مستودعات الشيفرة
- قيّم إمكانية بناء نموذج بديل للنماذج الخاصة
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«هل تشترطون على عملائكم من المؤسسات الذين يدمجون API النموذج لديكم فحص بيانات الاعتماد وأفضل ممارسات إدارة مفاتيح API؟ وهل لديكم مراقبة لحجم الاستعلامات لكل مفتاح من شأنها رصد محاولات الاستخراج المنهجية من أي من تكاملات عملائكم؟»
ما تتوقعه دليلًا
- متطلبات أمن API للعملاء من المؤسسات
- تأكيد مراقبة حجم الاستعلامات لكل مفتاح
- القدرة على كشف الاستخراج
- تقييم تهديد النموذج البديل
المورّد الذي يؤكد أمن API لديه ينبغي سؤاله عن أمن تكاملات عملائه من المؤسسات. فضوابط API لدى المورّد تحكم الوصول المباشر. أما تكاملات العملاء فهي السطح الممتد الذي يمكن الوصول من خلاله إلى النموذج بصورة غير مباشرة.
كيف تُثبت ذلك
- إدارة مفاتيح API في وثائق التكامل
- تطبيق فحص بيانات الاعتماد
- سجلات مراقبة الحجم لكل مفتاح
- إطار حماية الأسرار التجارية في مواجهة سرقة النماذج
الخلاصة الرئيسية
API المورّد: TLS متبادلة، وإدارة مفاتيح، وتحديد المعدل، وكشف الشذوذ. مستودع GitHub لدى العميل المؤسسي: مفتاح API مضمّن في الشيفرة. المهاجم: حصل على مفتاح API من GitHub. أربعمئة ألف استعلام. اليوم الثامن والعشرون: كشف الشذوذ يُطلق التنبيه. النموذج البديل: دُرّب. كان نموذج المورّد مؤمّنًا، لكنه سُرق عبر تكامل غير آمن لدى أحد العملاء. إن أمن API لدى المورّد ضابط ضد الهجوم المباشر، أما السطح الممتد عبر تكاملات العملاء فهو مسار الهجوم غير المباشر الذي لا يستطيع أمن المورّد سده وحده. ومراقبة الاستعلامات لكل مفتاح ترصد الاستخراج بصرف النظر عن المفتاح المستخدم، وفحص بيانات الاعتماد في مسارات العملاء يمنع وصول مفتاح API إلى GitHub. وكلاهما التزام على المورّد يمتد إلى متطلبات أمن التكامل لدى العملاء.