نحو نموذج أفضل للاستجابة للثغرات السحابية

على مدار العام الماضي، كشف فريق بحث Wiz عن العديد من الثغرات الأمنية السحابية الحرجة، مثل الثغرات الأمنية عبر الحسابات في AWS IAM، وChaosDB، وOMIGOD. وفي كل منها، كان هناك مستوى مذهل من عدم اليقين حول من هو المسؤول عن ماذا، بين فرق الأمن ومقدمي الخدمات السحابية (CSPs). وأدى هذا الافتقار إلى اليقين إلى إعاقة جهود الإصلاح التي يبذلها العملاء وزرع الارتباك بينهم وبين مقدمي خدمات الاتصالات. لقد أذهلني أنه على الرغم من مناقشة (إفراط) نموذج المسؤولية المشتركة في البنية التحتية السحابية، إلا أنه لا يمكن قول الشيء نفسه بالنسبة لنموذج الكشف عن الثغرات الأمنية والاستجابة لها في السحابة.

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

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

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

هذه هي بالضبط الطريقة التي استجاب بها مقدمو خدمات السحابة للثغرات السحابية التي اكتشفها Wiz وكشف عنها في وقت سابق من عام 2021. على سبيل المثال، عندما تم الكشف عن ثغرات AWS IAM عبر الحسابات، قامت AWS بتحديث وثائقها ونبهت العملاء الضعفاء عبر البريد الإلكتروني. بعد التحديث، تم ترك أي عملاء لم يتبعوا الخطوات اليدوية الموضحة مكشوفين. تم الكشف عن ChaosDB بشكل مسؤول لشركة Microsoft، التي أصلحت الثغرة الأمنية وقامت فقط بتحديث العملاء “المتأثرين بنشاط البحث”، عبر البريد الإلكتروني، مع وصف غامض للثغرة الأمنية والإجراءات اليدوية المطلوبة من جانبهم: تدوير المفاتيح وتكوين الوصول إلى الشبكة. أثارت عملية الإخطار الغامضة هذه استجابة جماعية بين العملاء ووسائل الإعلام.

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

دعونا نتعمق في ChaosDB للتفكير في نموذج المسؤولية المشتركة كما يتم التعامل معه اليوم.

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

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

2. من يحدد نطاق الإخطار؟ يعتقد باحثو Wiz أنه كان يتعين على Microsoft تحديث آلاف العملاء الآخرين.

3. كيف يمكن للعملاء فهم ما حدث بسهولة وكيفية الرد عليه؟ تضمنت التوجيهات المقدمة من Microsoft مجموعة كبيرة من روابط الوثائق التي كان من الصعب جدًا تجميعها معًا.

4. كيف يمكن للعملاء أو مقدمي خدمات الاتصالات التأكد من تنفيذ إجراءات الإصلاح المطلوبة؟ كانت استجابة ChaosDB هي تدوير مفاتيح سحابة Cosmos DB، لكن هذه المفاتيح لا تحتوي على سجل “آخر تحديث”.

5. بالنظر إلى وتيرة التغيير السريعة في السحابة، كيف يمكن للعملاء معرفة متى تتغير خطوط الأساس الأمنية الخاصة بهم؟ عندما تم تمكين Jupyter Notebooks افتراضيًا بواسطة Microsoft، لم يكن لدى العملاء طريقة ذات معنى لمعرفة تعرضهم الإضافي أو كيفية تعطيل “الميزة” الجديدة بشكل استباقي.

ℹ️للحصول على أمثلة إضافية، راجع منشور مدونتنا السابق حول الحاجة إلى قاعدة بيانات ثغرات سحابية.

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

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

• نقاط الضعف في CSP—عيوب في التعليمات البرمجية والحزم والتكوينات الافتراضية وما إلى ذلك في البنية التحتية التي يحتفظ بها مقدمو الخدمة السحابية بموجب نموذج المسؤولية المشتركة. على سبيل المثال، يرتبط ChaosDB بالتكامل بين خدمات Azure التي تم تمكينها (تقريبًا) بصمت افتراضيًا لجميع عملاء Azure.

• نقاط ضعف العملاء—عيوب في التعليمات البرمجية والحزم والتكوينات الافتراضية وما إلى ذلك في البنية التحتية التي يحتفظ بها العملاء بموجب نموذج المسؤولية المشتركة. على سبيل المثال، تضمنت ثغرة log4j التي تم الكشف عنها مؤخرًا (CVE-2021-44228)، إطار عمل تسجيل مفتوح المصدر شائعًا مضمنًا في العديد من التطبيقات المثبتة من قبل العملاء على البنية التحتية لمزود الخدمة السحابية (CSP).

مع أخذ هذا التمييز في الاعتبار، دعونا نحلل عملية الاستجابة الأمنية من حيث (1) تعداد التهديدات وخطورتها، (2) تقييم الموارد المتضررة، و (3) عمليات المعالجة للتخفيف من التهديدات.

ومن الواضح أن نقاط ضعف CSP لا يتم التعامل معها حاليًا بطريقة صارمة وشفافة.

يمكن أيضًا استخدام نفس الإطار الأساسي لتحليل المخاطر الناشئة عن ميزات السحابة التي تم إصدارها حديثًا (على سبيل المثال، Jupyter Notebooks المضافة إلى CosmosDB) وتكوينات الأمان التي يتحكم فيها العميل:

إن شؤون الحالة الحالية فيما يتعلق بالميزات السحابية وتكوينات الأمان تترك أيضًا الكثير مما هو مرغوب فيه.

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

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

أقترح النموذج التالي كنقطة انطلاق:

مسؤوليات CSP

يجب أن يكون مقدمو الخدمات السحابية مسؤولين عن:

تم تعداد معيار الأمان السحابي

سيكون معيار أمان السحابة المذكور عبارة عن قائمة معدودة مقدمة من البائع للتكوينات الآمنة المتاحة للعملاء، إلى جانب تصنيفات خطورتها وتحليلات الموقف. ويجب أن تتضمن هذه المعايير معيارًا لجميع الميزات التي قد تؤثر على الوضع الأمني ​​السحابي للعملاء، وإرشادات حول كيفية التحكم فيها (نأمل أن يكون ذلك برمجيًا). يجب تحديث التعداد مع إصدار ميزات جديدة تؤثر على نماذج التهديد حتى يتمكن العملاء من اتخاذ قرارات مستنيرة بشأن موقفهم. بأخذ Azure CosmosDB كمثال، فإن التكوينات التي يمكن تعدادها هي:

• AZ-COSMOSDB-101: تدوير المفاتيح

• AZ-COSMOSDB-102: تكوين قيود FW

• AZ-COSMOSDB-103: تمكين سجلات التشخيص

• AZ-COSMOSDB-104: تمكين نقاط النهاية الخاصة

سجل تغيير نموذج التهديد

سيتم التواصل مع سجل تغيير نموذج التهديد للعملاء عند توفر معيار جديد أو تحديثه. يجب أن تتدفق هذه المعلومات من مقدمي الخدمات السحابية إلى العملاء لأن مقدمي الخدمات السحابية يعرفون متى يقومون بإجراء تغييرات، مثل توصيل CosmosDB بـ Jupyter Notebook، مما يؤدي إلى إنشاء أسطح هجوم جديدة للعملاء.

قاعدة بيانات الضعف السحابي

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

هذه هي الطريقة التي كان ينبغي أن تبدو بها استشارة ChaosDB في التنسيق القياسي للثغرات السحابية:

مسؤوليات العملاء

يجب أن يكون العملاء مسؤولين عن:

إدارة الضعف

يتحمل العملاء ويجب أن يظلوا مسؤولين عن إدارة ومعالجة الثغرات الأمنية السحابية.

التكوين السحابي الصحيح

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

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

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