تأمين عناوين URL لوظيفة AWS Lambda

أطلقت AWS مؤخرًا عناوين URL لوظائف Lambda، وهي ميزة جديدة تسمح لمنشئي السحابة بإعداد نقاط نهاية تطبيق بسيطة ومخصصة لوظائف Lambda. يدعم مقدمو الخدمات السحابية الآخرون أيضًا ميزات مشابهة، مثل وظائف سحابة GCP HTTP ومشغلات HTTP لوظائف Azure.

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

مع تزايد اعتماد Serverless بين عملاء السحابة في السنوات الأخيرة، يبدو أن Serverless يجذب انتباه الجهات الفاعلة الخبيثة أيضًا، الذين يرون بطبيعة الحال قيمة في الاستفادة من شعبيتها. إحدى الحالات التي تم اكتشافها مؤخرًا هي حالة “Denonia”، وهي برامج ضارة تستهدف البيئات التي لا تحتوي على خوادم بغرض تثبيت أدوات تعدين العملات المشفرة (وإن كان ذلك لبضع ثوانٍ أو دقائق فقط في كل مرة، اعتمادًا على حد مهلة الوظيفة).

مخاطر الاستخدام غير الآمن لعناوين URL لوظيفة AWS Lambda

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

قد يكون عنوان URL الخاص بالوظيفة معرضًا لخطر الهجوم في الحالات التالية:

1. يكتشف المهاجم عنوان URL للوظيفة في بيئتك (سنتوسع في هذا في القسم التالي).

2. لقد تمت تهيئته بشكل خاطئ لقبول طلبات HTTP دون الحاجة إلى المصادقة.

3. تسمح سياسة موارد الوظيفة بالاستدعاء من قبل مديرين غير مصادقين. هذا هو الإعداد الافتراضي إذا لم يتم تكوين أي مصادقة.

4. يتعرف المهاجم على كيفية استخدام الوظيفة، أو بمعنى آخر، ما هي الوسائط التي تقبلها.

قد يكون المتطلب الأخير صعبًا ويعتمد على مدى تعقيد واجهة برمجة التطبيقات الخاصة بالوظيفة:

• الدالة التي لا تقبل أي وسيطات سيكون من السهل استدعاءها، في حين أن الدالة ذات المعلمات المتعددة سيكون من الصعب اختراقها.

• إن أي معرفة مسبقة قد تكون لدى المهاجم حول الوظيفة ستسمح له بإجراء تخمين أكثر استنارة حول كيفية عملها.

• إذا “سربت” الوظيفة معلومات، مثل إرجاع رسائل خطأ إعلامية، فإن ذلك سيسمح للمهاجم باستنتاج وسيطات صالحة من خلال التجربة والخطأ.

في السيناريو المذكور أعلاه، اعتمادًا على ما تفعله الوظيفة المستهدفة، يمكن للمهاجم أن يشكل مخاطر متعددة على البيئة السحابية المستهدفة:

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

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

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

بالإضافة إلى ذلك، حتى بدون الفهم الكامل للغرض من الوظيفة، يمكن للمهاجم الذي يسعى إلى تعطيل عمليات المؤسسة المستهدفة (لأي سبب كان) أن يقوم ببساطة بأتمتة الاستدعاء المتكرر للوظيفة، مما يؤدي إلى النتائج غير المرغوب فيها التالية:

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

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

من الاستطلاع إلى الاستدعاء

ولكن كيف يمكن للمهاجم اكتشاف عنوان URL الخاص بالوظيفة التي تم تكوينها بشكل خاطئ في المقام الأول؟ من الناحية النظرية، يمكنهم تعداد جميع عناوين URL للوظائف عن طريق الاستعلام عن بيانات DNS السلبية للنطاقات الفرعية التي تطابق التعبير العادي *.lambda-url.*.on.aws. وبالمناسبة، لن ينجح الاستعلام عن سجلات شفافية شهادة TLS، حيث يبدو أن Lambda تستخدم فقط شهادة بدل واحدة لكل منطقة، مثل *.lambda-url.us-west-2.on.aws بالنسبة لـ us-west-2، بدلاً من إصدار شهادة منفصلة لكل نطاق فرعي فريد. يمكن للمهاجم بعد ذلك محاولة الوصول إلى كل عنوان من عناوين URL هذه بدوره، ووضع علامة على تلك التي تسمح بالوصول غير المصادق لمزيد من البحث.

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

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

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

أفضل ممارسات أمان عنوان URL لوظيفة AWS Lambda

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

1. مصادقة IAM

مع تمكين مصادقة IAM (تم ضبط نوع المصادقة على AWS_IAM، وهو الإعداد الافتراضي)، لن يقبل عنوان URL الخاص بالوظيفة نفسه سوى طلبات HTTP إذا تم توقيعها بواسطة مفتاح وصول AWS، وفقط إذا كان هذا المفتاح ينتمي إلى مدير ذو صلاحية فعالة lambda:InvokeFunctionUrl الأذونات. وهذا يعني أنه بالنسبة للوصول إلى الحساب نفسه، يجب منحهم هذا الإذن من خلال سياسة الهوية الخاصة بهم، وبالنسبة للوصول عبر الحسابات، يجب أيضًا منحه هذا الإذن من خلال سياسة موارد الوظيفة، وإلا فسيتم رفض الطلب. وعلى نحو فعال، يضمن هذا أن مستخدمي AWS المصادق عليهم فقط هم الذين يمكنهم استدعاء الوظيفة عبر عنوان URL الخاص بها.

في المقابل، إذا تم تعطيل مصادقة IAM لعنوان URL للوظيفة عبر وحدة تحكم AWS (تم تعيين نوع المصادقة على NONE)، وهو أمر غير مستحسن، ستقوم AWS تلقائيًا بإرفاق سياسة الموارد التي تمنح الوصول العام (على سبيل المثال، * تعيين كمبدأ رئيسي ل lambda:InvokeFunctionUrl فعل). إذا قررت السماح باستدعاء غير مصادق للوظيفة عبر عنوان URL الخاص بها، فتأكد من أن الوظيفة لديها الحد الأدنى من الأذونات في بيئتك، وذلك لتقليل المخاطر. يمكنك أيضًا تنفيذ نظام مصادقة مخصص داخل الوظيفة نفسها كبديل لمصادقة IAM، ولكن هذا لا يعتبر من أفضل الممارسات.

2. إذن IAM

بالإضافة إلى مصادقة IAM، من خلال تكوين سياسة موارد IAM التي تحدد من يحق له استدعاء وظيفة، وتحت أي ظروف، وما إذا كان ذلك مباشرة (lambda:InvokeFunction) أو عبر عنوان URL الخاص به (lambda:InvokeFunctionUrl)، يمكنك قصر الاستدعاء بشكل صريح على مبادئ معينة، وبالتالي تقليل مخاطر التعرض العام. ومع ذلك، يجب عليك تجنب استخدام سياسات الموارد شديدة التساهل، مثل تعيين حرف بدل (*) كمبدأ أساسي للاستدعاء، إما بشكل مباشر أو عبر عنوان URL، لأن هذا من شأنه أن يسمح لأي مستخدم AWS مصادق عليه باستدعاء الوظيفة، ويمكن لأي شخص بشكل أساسي إنشاء حساب AWS.

3. كورس

إذا تم تمكين تكوين مشاركة الموارد عبر الأصل (CORS)، فسيقبل عنوان URL للوظيفة بشكل افتراضي طلبات HTTP من أي أصل (مجال)، وهو أمر غير مستحسن. لذلك، يجب عليك تكوين قيود CORS إضافية، مثل السماح فقط بطلبات HTTP من أصول محددة، أو الطلبات التي تحتوي على رؤوس محددة وطرق HTTP (GET, POST، إلخ.). ومع ذلك، لا تعد CORS حاجزًا أمنيًا قويًا في حد ذاتها، حيث يمكن انتحال الأصول، ويمكن للمهاجم نظريًا اكتشاف تفاصيل كيفية استدعاء الوظيفة (كما هو مذكور أعلاه)، بما في ذلك الرؤوس والأساليب المقبولة.

4. التزامن المحجوز

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

تأمين عناوين URL لوظيفة AWS Lambda باستخدام Wiz

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

على سبيل المثال، يمكنك استخدام Wiz للتحقق من وظائف Lambda باستخدام المجموعة التالية:

• يتعرض للإنترنت عبر عنوان URL أو موازن التحميل أو بوابة API.

• لا يتطلب مصادقة أو ترخيصًا مناسبًا، سواء كانت المشكلة ناجمة عن مصادقة IAM معطلة أو سياسة موارد متساهلة بشكل مفرط.

• مع امتيازات عالية في البيئة.

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

لمراقبة الحالة الأمنية لجميع الموارد بدون خادم في بيئتك وعرض ملخص للمشكلات المتعلقة بالسيناريوهات المتنوعة الموضحة هنا، يمكنك استخدام لوحة معلومات Wiz Serverless.

تمت كتابة منشور المدونة هذا بواسطة فريق أبحاث Wiz، كجزء من مهمتنا المستمرة لتحليل التهديدات التي تواجه السحابة، وبناء آليات تمنعها وتكتشفها، وتقوية استراتيجيات أمان السحابة.