كشفت Habr AI كيف يؤدي منفذ مفتوح واحد في منصة LLM إلى كشف مفاتيح API والبنية التحتية

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

كيف وجدوا الوصول

اختبر المدققون الخدمة مع عشرات الآلاف من المستخدمين واتبعوا في البداية المسار المتوقع لكومة LLM: فحصوا SSRF بالاقتران مع LangChain، جربوا حقن الأوامر، حللوا معالجة HTTP، وبحثوا عن ثغرات إلغاء التسلسل. المنطق مفهوم: هذه هي بالضبط المجالات التي يتم مناقشتها عادة عند الحديث عن أمان RAG والعوامل وتطبيقات LLM. لكن لا سلسلة من سلاسل الهجمات الطويلة أسفرت عن نتائج.

ظهر الاكتشاف الحاسم ليس في التطبيق، بل على مستوى البنية التحتية المؤمنة بشكل سيء.

"قمنا بـ curl واحد لمنفذ مفتوح — وحصلنا على جميع المفاتيح في 5 دقائق."

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

لماذا يحدث هذا

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

تتفاقم المشكلة بحقيقة أن شركات الذكاء الاصطناعي الناشئة غالباً ما تفكر في التهديدات على مستوى النموذج. يناقشون على نطاق واسع الاختراق والتسريب من موجهات النظام والهلوسة وحماية سياق RAG، لكنهم يؤجلون النظافة الكلاسيكية لـ DevSecOps. مع ذلك، فإن هذه النظافة بالذات هي التي تحدد ما إذا كان يمكن للمهاجم الوصول إلى الأسرار أو البنية التحتية السحابية أو مفاتيح API بقيمة مئات الآلاف من الدولارات. إذا كانت الخدمة الداخلية تستمع إلى الشبكة دون داع والأسرار متاحة لعملية "من باب الاحتياط"، فإن LLM لم يعد المشكلة الرئيسية — فهو يزيد ببساطة من تكلفة العواقب.

حيث تحدث الأخطاء بشكل متكرر

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

• المنافذ الداخلية المفتوحة والخدمات بدون قوائم التحكم في الوصول الصارمة
• الأسرار في متغيرات البيئة أو السجلات أو التكوينات المتاحة للخدمات المجاورة
• الأذونات الزائدة للحاويات والعدائين والحسابات الخدمية
• غياب التقسيم بين طبقة RAG ولوحة الإدارة والبنية التحتية السحابية
• التركيز على حقن الأوامر مع تجاهل نظافة الشبكة

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

ما يعنيه هذا

الاستنتاج الرئيسي بسيط: يجب حماية منتج الذكاء الاصطناعي ليس كـ "سحر LLM خاص"، بل كمنصة حرجة عادية مع أسرار مكلفة ونطاق تأثير واسع. إذا لم تكن البنية التحتية الأساسية مأمونة، فلن تساعد أي محادثة حول الهجمات المعقدة على النموذج — ستثبت باب واحد مفتوح أنه أكثر أهمية من كل بنيتك المعمارية للذكاء الاصطناعي.