النطاق والأدلة

تصف الدراسة البحثية الموثّقة تنفيذًا يحمل اسم Mine، وهو Proxy مبني على FastAPI ومتوافق مع OpenAI، يمرّر الطلبات إلى مزوّد upstream ويطبّق، بشكل مشروط، حالات الهجوم المحددة بالرموز AC-١ وAC-١.a وAC-١.b وAC-٢. ويصف المصدر نفسه وحدات مرافقة على جانب العميل لثلاث فئات من وسائل الحماية التي جرى تقييمها: بوابة لسياسات الأدوات، وفحص الشذوذ على مستوى الاستجابات، وسجل شفافية يعمل بنمط الإضافة فقط.

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

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

الخطوة ١: فهم نموذج تهديد الوسيط

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

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

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

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

الخطوة ٢: رسم خريطة للبيانات التي تمر عبر الموجّه

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

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

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

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

الخطوة ٣: الفصل بين سلامة الطلب وسلامة الاستجابة وصلاحيات الأدوات

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

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

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

الخطوة ٤: مراجعة فئات الحماية الواردة في البحث

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

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

فحص الشذوذ على مستوى الاستجابة

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

سجل شفافية يعمل بنمط الإضافة فقط

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

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

الخطوة ٥: تفسير غلاف الاستجابة الموقّع بحذر

يسرد المصدر الموثّق حقولًا لغلاف استجابة موقّع. وتشمل هذه الحقول إصدار الغلاف (v) للتوافق وطرح الإصدارات؛ وهوية المزوّد؛ ومعرّف مفتاح التوقيع للتحقق والتدوير؛ ومعرّف النموذج المرتبط بالاستجابة الموقّعة؛ وnonce يقدمه العميل ومربوط بالطلب المقابل؛ والطوابع الزمنية لإصدار المزوّد وانتهاء الصلاحية؛ ومحتوى المساعد، إن وُجد؛ واستدعاءات الأدوات مع الأسماء والوسائط بصيغة native-JSON؛ وسبب الإنهاء؛ ومعرّف خوارزمية التوقيع.

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

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

الخطوة ٦: إعداد سجل مراجعة يستند إلى المصادر

في التقييم الداخلي، سجّل إصدار الورقة والادعاءات الدقيقة التي تحققت منها. وافصل بين ما يذكره المصدر وقرارات التنفيذ الخاصة بك. فعلى سبيل المثال، «تصف الورقة Proxy مبنيًا على FastAPI ويمرّر طلبات متوافقة مع OpenAI» عبارة على مستوى المصدر. أما «تمنع خدمتنا كل عمليات التلاعب بالـ Prompt» فهو ادعاء أمني مستقل لا يثبته السياق المقدم.

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

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

أخطاء شائعة ينبغي تجنبها

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

الخلاصة

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

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

ملاحظة تحريرية: يقتصر هذا المقال على السياق الموثّق المقدم. ولا يدّعي أن المرفقات البحثية الموصوفة خدمة إنتاجية، أو أنها توفر حماية شاملة.