القضية الغامضة لتعرّض البيانات العابر

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

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

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

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

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

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

ثانيًا، هذه حالة يصعب منعها بالكامل عبر سياسات التحكم في الخدمات (Service Control Policies). فلا يوجد مفتاح شرط لمنع نسخ RDS العامة، ولا توجد مفاتيح شروط لمنع فتح منافذ قواعد البيانات (أو أي منافذ) في مجموعات الأمان.

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

رابعًا، نظرًا لمحدودية الخيارات الوقائية المتاحة، يجب الاستعانة بالضوابط الكشفية والتصحيحية. في هذه الحالة، يمكنكم اكتشاف استدعاء CreateDBInstance API مباشرة والتحقق من المعامل PubliclyAccessible=True. كما يُوصى بشدة بالمراقبة المستمرة باستخدام CSPM (مرة أخرى، من مزود الخدمة السحابية لديكم أو من مورّد مثلنا) لرصد نسخ RDS العامة. أما على صعيد المعالجة، فأحد الخيارات هو إنهاء النسخة فور اكتشاف إنشائها. غير أن النهج الأفضل قد يكون استخدام ModifyDBInstance لإزالة المعامل PubliclyAccessible. وإذا فعلتم ذلك، فمن المهم ألا تطبّقوا هذه الأتمتة إلا في بيئة نشر تتأكدون فيها من أن نسخ RDS العامة لن يُسمح بها. فاليوم الذي تعطّلون فيه اتصال قاعدة بيانات متوقعًا ومُصرّحًا به ظل يعمل 3 سنوات لأنكم لم تتواصلوا مع الفريق هو على الأرجح يوم مناسب لإخراج سيرتكم الذاتية.

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

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

المتحدث الضيف

Rich Mogull

النائب الأول للرئيس لأمن السحابة، FireMon
يشغل Rich منصب النائب الأول للرئيس لأمن السحابة في FireMon، حيث يركّز على أبحاث أمن السحابة المتقدمة وتطبيقها. انضم Rich إلى FireMon عبر الاستحواذ على DisruptOps، وهي منصة لأتمتة أمن السحابة قائمة على أبحاثه خلال توليه منصب الرئيس التنفيذي لشركة Securosis. ولديه أكثر من 25 عامًا من الخبرة في مجال الأمن، وهو متخصص حاليًا في أمن السحابة وDevSecOps، بعد أن بدأ العمل العملي في السحابة قبل نحو 10 سنوات. وقبل تأسيس Securosis وDisruptOps، شغل Rich منصب نائب رئيس الأبحاث في Gartner ضمن فريق الأمن.