حين يهزم سرعة الذكاء الاصطناعي أمانه
فاق انتشار نشر الذكاء الاصطناعي في المؤسسات ممارسات الأمان بهامش واسع. كشف تحليل جديد موثق في The Hacker News فحص نحو مليون خدمة ذكاء اصطناعي مكشوفة على الإنترنت، مستمَدة من مليوني مضيف تم تحديدهم عبر سجلات شفافية الشهادات، عن أخطاء تكوين متفشية في أدوات تنسيق الذكاء الاصطناعي ومُغلِّفات LLM والمنصات العاملة باستقلالية.
النتائج محددة ومقلقة. من بين أكثر من 5,200 خادم Ollama تمّ الاستعلام عنها، استجاب 31% لطلبات المصادقة دون الحاجة إلى بيانات اعتماد — أي نحو 1,600 نسخة مفتوحة لأي شخص على الإنترنت. Ollama هي منصة استضافة LLM محلية يستخدمها المطورون لتشغيل نماذج مثل Llama 3 وMistral وQwen محلياً أو على الخادم؛ تكشف نسخة Ollama المفتوحة ليس فقط نقطة نهاية LLM بل أيضاً أي بيانات ومنطق أعمال يمكن الوصول إليه عبرها. عبر الفحص الأشمل، تم التعرف على 518 نسخة من نماذج LLM الرائدة — وكلاء API من إنتاج GPT-4 وClaude وGemini متاحون بلا مصادقة. عُثر على أكثر من 90 نسخة مكشوفة في قطاعات حكومية وتسويقية ومالية.
يضيف تقرير OWASP GenAI للربع الأول من 2026 سياقاً إضافياً: وُجد ما بين 12,000 و15,000 نسخة من Flowise معرضة للاستغلال النشط في الفترة ذاتها. Flowise هو أداة بناء سير عمل الذكاء الاصطناعي بدون كود تُستخدم لإنشاء خطوط RAG وواجهات الدردشة والآليات عاملة بالذكاء الاصطناعي. تمنح نسخة Flowise المكشوفة المهاجمين وصولاً ليس فقط لنقطة نهاية LLM بل للمنطق التجاري الكامل المدمج في سير العمل — الذي قد يشمل اتصالات قواعد البيانات وبيانات اعتماد API وبيانات العملاء وتعريفات العمليات الداخلية.
يضيف هجوم سلسلة توريد LiteLLM في مارس 2026 بُعداً ثالثاً: 36% من البيئات السحابية كانت تحتوي على LiteLLM، مكتبة Python التي توحّد الوصول إلى API لموفري LLM المتعددين. حين اخترق المهاجمون حساب المشرف على PyPI ونشروا الإصدارين الضارين 1.82.7 و1.82.8، كان بإمكانهم الوصول المحتمل للبنية التحتية للذكاء الاصطناعي في أكثر من ثلث البيئات السحابية.
أنماط التكوين الخاطئ الثلاثة التي تُمكّن الكشف الجماعي
النمط 1: تعطيل المصادقة عند التثبيت
لا تُفعّل Ollama وn8n وFlowise وعدة منصات ذكاء اصطناعي أخرى المصادقة بشكل افتراضي. يُطلق المطورون نسخاً وفق أدلة البدء السريع التي تركز على جعل الذكاء الاصطناعي يعمل لا على تأمينه. وجد تحليل OWASP “عدداً كبيراً من المضيفين نُشروا مباشرة دون أي مصادقة”. نظراً لأن هذه المنصات تتطلب غالباً صلاحيات مرتفعة للتعامل مع موارد GPU، تستخدم عملية الإطلاق الافتراضية حسابات من مستوى root أو عالية الامتياز — مما يعني أن نقطة نهاية غير مصادقة تمنح وصولاً مكافئاً لـ root.
النمط 2: بيانات الاعتماد المدمجة في البنية التحتية كبرمجة
وجد الفحص بيانات اعتماد مُرمَّزة وثابتة في أمثلة الإعداد وملفات docker-compose عبر منصات ذكاء اصطناعي متعددة. كثيراً ما تشمل أمثلة Docker Compose لـ Flowise وn8n وأدوات مماثلة مفاتيح API وكلمات مرور قواعد البيانات كمتغيرات بيئة بنص عادي. حين تُودَع هذه الملفات في مستودعات عامة أو شبه عامة، تكشف بيانات اعتماد الإنتاج. استغل هجوم LiteLLM هذا النمط: استهدفت المرحلة الثانية من البرمجيات الضارة تحديداً ملفات .env لأن متغيرات البيئة هي الطريقة الأساسية التي تتلقى بها أُطر الذكاء الاصطناعي مفاتيح API.
النمط 3: تكوينات Docker غير الآمنة
خدمات الذكاء الاصطناعي التي تعمل في حاويات Docker كثيراً ما ترث تكوينات مفرطة التسامح: تركيب مقبس Docker (مما يمنح قدرات الإفلات من الحاوية)، والتشغيل كـ root داخل الحاوية، وتعطيل ملفات seccomp أو AppArmor، وكشف جميع المنافذ لجميع الواجهات.
إعلان
ما يجب على فرق أمن المؤسسات فعله حول البنية التحتية للذكاء الاصطناعي
1. إجراء جرد فوري لجميع خدمات الذكاء الاصطناعي في بيئتك
قبل تطبيق أي إصلاح للتكوين، تحتاج إلى معرفة ما هو موجود. أجرِ فحصاً شاملاً لاكتشاف خدمات الذكاء الاصطناعي: استعلم عن كتالوج خدمات مزود السحاب الخاص بك لجميع نسخ الحوسبة المُصنَّفة بعلامات ذات صلة بالذكاء الاصطناعي؛ وتحقق من منصة تنسيق الحاويات الخاصة بك (Kubernetes وECS وDocker Swarm) للصور التي تعمل من سجلات الذكاء الاصطناعي الشائعة (Ollama وFlowise وn8n وLangChain وHugging Face Inference)؛ وراجع سجلات وصول CDN والوكيل العكسي للحركة إلى المنافذ 11434 (افتراضي Ollama) و3000 (n8n) و3001 (Flowise) و8080 (وكيل API LLM شائع). المؤسسات التي تتخطى هذه الخطوة ستقضي أشهراً في اكتشاف عمليات نشر الذكاء الاصطناعي غير الرسمية بشكل تفاعلي بدلاً من استباقي.
2. فرض المصادقة على كل نقطة نهاية لخدمة الذكاء الاصطناعي
يجب أن تتطلب كل خدمة ذكاء اصطناعي يمكن الوصول إليها من شبكة مصادقةً. بالنسبة لـ Ollama، يعني ذلك وضع وكيل عكسي مُصادَق (Nginx + مصادقة أساسية، أو OAuth2-Proxy مع موفر هوية) أمام نقطة نهاية Ollama، وربط Ollama بـ localhost (127.0.0.1) بدلاً من جميع الواجهات (0.0.0.0). بالنسبة لـ Flowise، فعّل المصادقة المدمجة في تكوين البيئة (FLOWISE_USERNAME وFLOWISE_PASSWORD)، وللنسخ الإنتاجية أضف OAuth2 أو SAML SSO. بالنسبة لـ n8n، فعّل المصادقة الأساسية المدمجة أو هيّئ خيارات SSO المؤسسية. لأي وكيل أو مُغلّف API LLM مخصص، طبّق على الأقل مصادقة بمفتاح API ودوّر تلك المفاتيح كل ثلاثة أشهر.
3. مراجعة وتدوير جميع مفاتيح API للـ LLM في بيئتك
استهدف هجوم LiteLLM تحديداً مفاتيح API للـ LLM المخزنة في متغيرات البيئة. أثّرت موجة سلسلة التوريد في مارس 2026 على 36% من البيئات السحابية التي تحتوي على LiteLLM. لكل خدمة ذكاء اصطناعي في جردك من الخطوة 1: حدّد مفاتيح API المستخدمة (OpenAI وAnthropic وAzure OpenAI وGoogle Gemini ورموز Hugging Face)، دوّر كل مفتاح بإنشاء مفتاح جديد في لوحة تحكم المورد وتحديث مدير أسرارك، ألغِ المفتاح القديم، وأكّد إعادة تشغيل الخدمة بنجاح مع المفتاح الجديد. خزّن جميع مفاتيح API للـ LLM في مدير أسرار مؤسستك (AWS Secrets Manager وHashiCorp Vault وAzure Key Vault)، لا في ملفات .env أو تكوينات Docker Compose أو ملفات تكوين التطبيق المودَعة في التحكم بالإصدار.
الصورة الأشمل: البنية التحتية للذكاء الاصطناعي تنضم إلى سطح الهجوم
تمثل الفترة 2025-2026 الدورة الكاملة الأولى لوجود البنية التحتية للذكاء الاصطناعي في البيئات المؤسسية على نطاق واسع — ويكتشف قطاع الأمن ما اكتشفه قطاع أمن الشبكات مع البنية التحتية السحابية بين 2012 و2018: أن الاعتماد السريع يخلق سطح هجوم لم تتعلم ممارسات الأمان بعد كيفية إدارته.
وثّق تقرير OWASP GenAI للربع الأول من 2026 ثمانية حوادث أمنية كبرى للذكاء الاصطناعي بين يناير وأبريل 2026، بما فيها نحو 150 جيجابايت من بيانات حكومة المكسيك مكشوفة عبر تكوين خاطئ لعميل ذكاء اصطناعي، و513,000 سطر من الخرائط المصدرية لـ Anthropic مسرَّبة عبر CDN مُهيَّأ بشكل خاطئ، وعدة منصات عميل سحابية مخترقة عبر تصعيد الامتيازات.
للمسؤولين التنفيذيين عن أمن المعلومات، التداعية واضحة: يجب دمج البنية التحتية للذكاء الاصطناعي في دورة إدارة الثغرات المعيارية. يعني ذلك عمليات تدقيق ربع سنوية لتكوينات مصادقة خدمات الذكاء الاصطناعي، وإدراج منصات الذكاء الاصطناعي في نطاق اختبارات الاختراق، وإدارة إلزامية للأسرار لجميع مفاتيح API للـ LLM، وSLA للتصحيح لتحديثات أُطر الذكاء الاصطناعي يُضاهي الإلحاح المطبَّق على حادثة LiteLLM.
الأسئلة الشائعة
ما منصات الذكاء الاصطناعي الأكثر سوء تكوين وتعرضاً؟
وجد الفحص Ollama (31% من أكثر من 5,200 نسخة مفتوحة بلا مصادقة) وFlowise (12,000-15,000 نسخة معرضة للاستغلال النشط) وn8n كأكثر المنصات تكوينا خاطئاً. علاوة على ذلك، وُجدت 518 نسخة من نماذج LLM الرائدة (وكلاء API لـ GPT-4 وClaude وGemini) متاحة بلا مصادقة. أثّر هجوم LiteLLM على 36% من البيئات السحابية. بيانات الاعتماد المُرمَّزة في ملفات Docker Compose والتطبيقات التي تعمل كـ root كانت أكثر التكوينات الخاطئة المحددة شيوعاً.
ما البيانات المعرضة للخطر إذا كانت خدمة الذكاء الاصطناعي غير مصادق عليها؟
تكشف خدمة ذكاء اصطناعي مفتوحة ليس فقط نقطة نهاية LLM بل كل ما يتصل بها: منطق الأعمال المدمج في سير عمل الذكاء الاصطناعي، وسلاسل اتصال قواعد البيانات وبيانات الاعتماد، وبيانات العملاء المتاحة عبر خطوط RAG، ومفاتيح API لخدمات أخرى مدمجة في سير عمل الذكاء الاصطناعي، وتاريخ المحادثات وسجلات الدردشة التي تحتوي على معلومات مستخدم حساسة، وفي حالة الأنظمة العاملة باستقلالية القدرة على تشغيل إجراءات (إرسال بريد إلكتروني وتعديل قواعد بيانات واستدعاء واجهات API خارجية) بلا تفويض.
كيف يجب على المؤسسات إدارة مفاتيح API للـ LLM بشكل آمن؟
يجب تخزين مفاتيح API للـ LLM (OpenAI وAnthropic وAzure OpenAI وGoogle Gemini) حصرياً في مدير أسرار مخصص — AWS Secrets Manager وHashiCorp Vault وAzure Key Vault وGCP Secret Manager. لا تخزّنها أبداً في ملفات .env أو ملفات Docker Compose YAML أو ملفات تكوين التطبيق أو مستودعات التحكم بالإصدار. دوّر المفاتيح كل ثلاثة أشهر وفور أي حادثة سلسلة توريد تؤثر على مكتبات الذكاء الاصطناعي في شجرة تبعياتك. نفّذ مفاتيح API لكل خدمة على حدة (مفتاح واحد لكل تطبيق لا مفتاح مؤسسي مشترك) حتى لا تُكشف جميع الخدمات عند اختراق خدمة واحدة.
