التهيئات الخاطئة لشرودنغر

إنه بعد ظهر يوم الخميس وتستعدون لمغادرة العمل مبكرًا بعض الشيء لأن… بإمكانكم ذلك. لكن حينها يُطلق ذلك المزعج موصِّل الإشعارات (المعروف أيضًا باسم Slack) رسالة جديدة في قناة التنبيهات الأمنية لديكم:

حسنًا، يا للأسف. لقد جعل أحدهم للتو نسخة لحظية من وحدة تخزين عامة. هل هذا هجوم؟ أم خطأ؟ أم شخص لا يعرف ببساطة ما هي السياسات؟

للتهيئات الخاطئة ثلاث حالات وجود

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

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

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

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

هناك 5 خصائص للسحابة تدعم هذا المفهوم:

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

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

افترضوا وجود هجوم حتى يثبت العكس

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

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

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

وبما أنه يتعين عليّ تبسيط الأمور لصفوف التدريب، فقد توصلت إلى ثلاثة مصادر أساسية لبيانات القياس الأمني:

• السجلات
• أحداث مزود السحابة (مثل أحداث Security Hub)
• التهيئات الخاطئة السحابية، التي يمكن أن تأتي من أداة CSPM لديكم أو من ماسحات مفتوحة المصدر أو ما شابه

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

داخليًا (وفي منصة DisruptOps) نتعامل مع هذا عبر مجموعة من كاشفات التهديدات في الوقت الفعلي التي تُطلق عمليات تقييم استنادًا إلى استدعاءات API المحددة. ويستغرق الأمر نحو 15-30 ثانية لتحديد تهيئة خاطئة وإرسالها إلى الأمن وإلى مالك المشروع عبر Slack (أو Teams) كما ترون أعلاه. وتُعامَل هذه التنبيهات بالطريقة نفسها التي تُعامَل بها نتائج GuardDuty أو أي مؤشر اختراق آخر، لكن استخدام ChatOps للتحقق من الأنشطة يساعدنا أيضًا على فرز هذه الحالات بسرعة كبيرة دون الحاجة إلى إجراء تحليل معمق في كل مرة.

التوصية باختصار: عالجوا التهيئات الخاطئة السحابية الرئيسية في وقت شبه فعلي وتعاملوا معها كمؤشرات اختراق حتى يثبت العكس.

لم تتعرض أي قطة للأذى أثناء كتابة هذه التدوينة.