كل المقالات

دوال السحابة المكشوفة: بوابة الاختراق التي يتجاهلها كثيرون

عمر حسن15 يوليو 2026 في 8:21 م6 دقيقة للقراءة

أبرز النقاط

  • الدوال السحابية المكشوفة للعموم دون مصادقة تُعدّ نقطة دخول أولى شائعة للمهاجمين
  • استغلال ثغرات مثل LFI وCommand Injection يمنح المهاجم تحكماً كاملاً بالحاوية ومنها بالبيئة السحابية
  • تطبيق مبدأ أقل صلاحية وتفعيل المصادقة الإلزامية خطوتان حاسمتان لأي نشر Serverless

كشفت Mandiant —ذراع استخبارات التهديدات في Google Cloud— أن تقييماتها الأمنية ترصد باستمرار تطبيقات Serverless مكشوفة للإنترنت بلا أي طبقة مصادقة، وهو واقع ينشأ أحياناً من متطلبات عمل مشروعة لكنه يفتح باباً واسعاً للمهاجمين. الخلاصة: دالة سحابية واحدة غير محمية قد تتحول إلى نقطة انطلاق تنتهي بسيطرة كاملة على البيئة السحابية للضحية.

Advertisement

ما الدوال السحابية ولماذا تنتشر بهذه السرعة؟

الدوال السحابية أو ما يُعرف بـ Function-as-a-Service (FaaS) تسمح بنشر كتل كود منفصلة كخدمات مصغّرة ضمن معمارية مرنة وحدثية دون الحاجة لإدارة خوادم. خدمات مثل Google Cloud Run وAWS Lambda وAzure Functions تتولى التوسع التلقائي والنشر الفوري، مما يزيل العبء التشغيلي ويُسرّع وقت الوصول للسوق.

تُشغّل هذه البنية اليوم منصات التجارة الإلكترونية الكبرى وبوابات الدفع وتطبيقات الذكاء الاصطناعي التوليدي. التوسع الهائل في اعتماد نماذج مثل chatbot interactions وتوليد الصور وأدوات vibe-coding يعتمد في جوهره على دوال Serverless لتنفيذ المهام. هذا النمو جعل تأمين بيئات Serverless تحدياً ملحّاً لفرق الأمن في المؤسسات.

كيف يستغل المهاجمون الدوال المكشوفة؟

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

  • Local File Inclusion (LFI) وRemote File Inclusion (RFI): قراءة ملفات حساسة من الحاوية أو تحميل شيفرة خارجية
  • Command Injection: تنفيذ أوامر نظام تشغيل على الحاوية الأساسية

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

  • استخراج أسرار مُخزّنة مباشرة في الشيفرة: مفاتيح API، بيانات اعتماد قواعد البيانات، رموز المصادقة
  • تحليل منطق التطبيق للكشف عن نقاط ضعف إضافية
  • سرقة Bearer Tokens لحسابات الخدمة من خادم البيانات الوصفية (Metadata Server) بعد تحقيق Remote Code Execution

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

70%+
من اختراقات السحابة تعود جذورها إلى أخطاء تهيئة وفق تقارير أمن السحابة

سيناريو عملي: ثغرة LFI في Cloud Run

قدّمت Mandiant مثالاً مبسطاً لدالة Python/Flask على Cloud Run تقبل مدخلاً من المستخدم لفتح ملف دون أي تحقق. في هذا النمط، يستطيع المهاجم إرسال طلب POST يحتوي على مسار ملف حساس:

يُرسل المهاجم طلباً مثل: {"file": "main.py"} ويحصل على الشيفرة المصدرية الكاملة للدالة. من تحليلها يستخرج مفاتيح API المُضمّنة، ونقاط حقن إضافية، وعناوين خدمات داخلية، وحزم مستوردة قد تحتوي ثغرات CVE معروفة.

الأخطر أن تسلسلات ../ التقليدية تتيح الوصول إلى ملفات نظام حساسة مثل /etc/passwd أو متغيرات البيئة التي تحوي بيانات اعتماد.

Advertisement

خطوات التقوية: كيف تحمي دوالك السحابية؟

رغم أن تحليل Mandiant ركّز على Google Cloud Run، فإن المبادئ تنطبق على أي نشر Serverless عام. إليك الإجراءات الأساسية:

  • فرض المصادقة دائماً: لا تترك دالة مكشوفة للعموم إلا إذا كانت الحاجة التجارية قاطعة، وحينها أضف طبقة تحقق من الهوية
  • تطبيق مبدأ أقل صلاحية: امنح حساب الخدمة الصلاحيات الدنيا اللازمة فقط، وتجنب أدوار Editor أو Owner
  • التحقق من المدخلات: لا تمرر أي مدخل من المستخدم مباشرة إلى دوال ملفات أو أوامر نظام، استخدم قوائم بيضاء صارمة
  • إدارة الأسرار مركزياً: لا تُخزّن مفاتيح API أو كلمات المرور في الشيفرة، استخدم Secret Manager أو Vault
  • مراجعة الحزم المستوردة: فحص الثغرات المعروفة في التبعيات باستخدام أدوات مثل Snyk أو Dependabot
  • تقييد الوصول للميتاداتا: قلّل ما يمكن للدالة قراءته من خادم البيانات الوصفية

لماذا يتسارع الخطر مع انتشار الذكاء الاصطناعي؟

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

ℹ️

رأي Logicity

ما تطرحه Mandiant ليس جديداً نظرياً، لكنه يكتسب إلحاحاً عملياً مع موجة Serverless التي يقودها الذكاء الاصطناعي. المؤسسات التي تبني وكلاء AI بسرعة غالباً ما تُهمل الأساسيات: مصادقة الدوال وإدارة الأسرار. أدوات مثل Wiz وOrca Security تقدم رؤية شاملة لوضع السحابة بأسعار تبدأ من آلاف الدولارات سنوياً للفرق الصغيرة، بينما توفر AWS IAM Access Analyzer وGoogle Cloud Security Command Center طبقات مجانية أو منخفضة التكلفة للبداية. الاستثمار في هذه الأدوات أرخص بكثير من تكلفة اختراق واحد.

أسئلة شائعة

الأسئلة الشائعة

ما الفرق بين Cloud Functions وCloud Run؟

Cloud Functions مصممة لدوال قصيرة تُشغَّل بحدث واحد، بينما Cloud Run يشغّل حاويات كاملة ويدعم طلبات HTTP مستمرة وتحكماً أكبر بالبيئة.

هل تنطبق هذه المخاطر على AWS Lambda وAzure Functions؟

نعم، المبادئ ذاتها تنطبق: أي دالة Serverless مكشوفة بلا مصادقة وتقبل مدخلات غير موثوقة معرضة لهجمات LFI وCommand Injection.

كيف أعرف إن كانت دوالي مكشوفة للعموم؟

استخدم أدوات فحص الوضع الأمني مثل Google Security Command Center أو AWS Access Analyzer أو أدوات طرف ثالث مثل Wiz لاكتشاف الدوال ذات الوصول العام.

ما أول خطوة لتأمين دالة موجودة؟

فعّل المصادقة الإلزامية فوراً، ثم راجع صلاحيات حساب الخدمة وطبّق مبدأ أقل صلاحية.

ℹ️

هل تحتاج مساعدة في التطبيق؟

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

Advertisement
ع

عمر حسن

كاتب تقني وابتكار

أُنتِج هذا المقال بمساعدة الذكاء الاصطناعي وراجعه فريق التحرير في لوجيسيتي. اعرف المزيد في سياسة التحرير.

اقرأ أيضاً