تقديم PEACH، وهو إطار عمل لعزل المستأجر للتطبيقات السحابية

على مدار العام ونصف العام الماضيين، اكتشف باحثو Wiz وأعضاء آخرون في مجتمع أمان السحابة العديد من نقاط الضعف المشتركة بين المستأجرين في العديد من التطبيقات السحابية متعددة المستأجرين (بما في ذلك ExtraReplica وHell’s Keychain). من المحتمل أن تكون كل من نقاط الضعف الحرجة هذه قد مكنت الجهات الفاعلة الضارة من الوصول إلى البيانات الخاصة بأي من عملاء التطبيقات المتأثرة.

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

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

ومع مرور الوقت، بدأنا نلاحظ وجود نمط إشكالي:

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

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

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

قادنا هذا النمط إلى تطوير PEACH، بهدف نمذجة عزل المستأجر في التطبيقات السحابية، وتقييم الوضع الأمني، وتحديد طرق تحسينه إذا لزم الأمر.

باستخدام الخوخ

يتضمن الجزء الأول من عملية مراجعة الأمان مراجعة عزل المستأجر. تحلل مراجعة العزل هذه المخاطر المرتبطة بالواجهات التي تواجه العملاء وتحدد:

1. تعقيد الواجهة كمتنبئ بالضعف؛

2. ما إذا كانت الواجهة مشتركة أو مكررة لكل مستأجر

3. ما هو نوع الحدود الأمنية الموجودة (مثل الأجهزة الافتراضية)؛

4. كيف بقوة وقد تم تنفيذ هذه الحدود.

من أجل قياس مدى قوة تنفيذ الحدود الأمنية (4)، نقترح استخدام المعلمات الخمس التالية (خَوخ):

صتصلب الامتياز

هتصلب التشفير

أتصلب المصادقة

جتصلب الاتصالية

حygiene

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

دراسة الحالة – ​​ChaosDB

كانت ChaosDB عبارة عن ثغرة أمنية مشتركة بين المستأجرين في Azure Cosmos DB تم الكشف عنها بواسطة Wiz في أغسطس 2021، والتي كان من الممكن أن تسمح للجهات الفاعلة الخبيثة بالوصول إلى البيانات التي تخص أي عميل Cosmos DB. يتألف تسلسل الهجوم من نشر Jupyter Notebook المضمن، واستغلال ثغرة أمنية محلية لتصعيد الامتيازات، وتعديل قواعد جدار الحماية للحصول على وصول غير مقيد إلى الشبكة، والمصادقة على الواجهة الخلفية لـ CosmosDB، وإساءة استخدام هذا الوصول لاسترداد وفك تشفير بيانات اعتماد المستأجرين الآخرين.

باستخدام إطار عمل PEACH لنمذجة الحالة الأولية لـ Cosmos DB قبل الكشف عن ChaosDB، يمكننا إجراء تحليل السبب الجذري للثغرة الأمنية. على حد فهمنا، تم تشغيل Jupyter Notebook المضمن لكل مستأجر في حاوية متداخلة داخل جهاز افتراضي. على الرغم من أن هذا قد يبدو وكأنه مخطط عزل قوي، إلا أن عوامل تصلب الواجهة كشفت عن ثغرات حرجة على مستوى التنفيذ:

1. امتياز فجوة التعزيز – جهاز افتراضي مخصص للمستأجر مع إمكانية الوصول إلى شهادة المسؤول المشتركة.

2. التشفير فجوة التصلب – مفاتيح API للمستأجر مشفرة بمفتاح مشترك.

3. المصادقة فجوة التصلب – لم يتم التحقق من صحة الشهادة الموقعة ذاتيًا.

4. الاتصال فجوة التعزيز – يتم فرض عناصر التحكم في الشبكة فقط داخل الحاوية (iptables) وواجهة المنسق التي يمكن الوصول إليها من الحاوية المستأجرة.

5. صحة الفجوة – وصول المستأجر إلى الشهادات والمفاتيح غير ذات الصلة.

في حين أن نظام العزل هذا يمكن أن يضمن عزل المستأجر للواجهات البسيطة نسبيًا، إلا أنه غير مناسب للواجهات المعقدة للغاية مثل Jupyter Notebook. في حالة ChaosDB، أدى هذا التعقيد إلى ثغرات PEACH التي مكنت في النهاية من الكشف عن تسلسل هجومنا.

الشروع في العمل مع الخوخ

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

فقط خوخي

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

سيكون من دواعي سرورنا تلقي تعليقاتك حتى نتمكن من تحسين إطار العمل وجعله مفيدًا قدر الإمكان لمطوري التطبيقات السحابية – فلا تتردد في التواصل معنا مباشرةً أو إنشاء مشكلة في مستودع GitHub الخاص بنا.

ترقبوا منشوراتنا المستقبلية على المدونات حول وضع إطار عمل PEACH موضع التنفيذ.

شكر وتقدير

نود أن نعرب عن امتناننا لكريستوف باريسيل (كبير مهندسي الأمن السحابي، Société Générale)، كفير كوهين (مهندس برمجيات الموظفين، Google)، كات تراكسلر (باحث الأمن الرئيسي، VectraAI)، سريناث كوروفادي (رئيس الأمن السحابي، Netflix)، جوزيف كجار (مهندس أول الأمن السحابي، Netflix)، مايك كون (المدير الإداري، Coalfire)، دانييل بيتنر (البرمجيات) Architect، IBM Cloud)، وآدم كاليس (مهندس أمن المعلومات، Cisco) لمشاركة المدخلات البناءة خلال تطوير هذا الإطار. نود أيضًا أن نشكر AWS على مراجعتها للورقة البيضاء الخاصة بنا والتعليقات القيمة التي قدمتها. نحن نقدر بشدة استعدادهم لمساعدتنا في تحديد أفضل ممارسات عزل المستأجر والتزامهم بتحسين الشفافية الأمنية لعملاء السحابة.