ما الذي حدث: تعرّض Salesforce وServiceNow

أشارت نشرة أمنية أسبوعية حديثة من Help Net Security إلى قصة تستحق أكثر من مجرد ذكر عابر: بوابات عملاء Salesforce وServiceNow تُركت مكشوفة لمدة 17 شهرًا تقريبًا قبل ظهور المشكلة إلى النور. وقد جمعت النشرة، التي غطت أيضًا استغلال ثغرة يوم-صفر في Metabase وتوسيع تنبيهات البرمجيات الخبيثة في Dependabot التابع لـGitHub، هذه العناصر معًا لسبب ما. إذ يوضح كل منها نكهة مختلفة من المشكلة الأساسية نفسها: منصات برمجيات المؤسسات، سواء كانت أدوات تحليلات ذاتية الاستضافة، أو مستودعات أكواد، أو أنظمة CRM سحابية، لا تكون آمنة إلا بمقدار الإعدادات والممارسات المتبعة من البائعين خلفها.

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

لماذا يهم تأخر الاكتشاف لمدة 17 شهرًا بالنسبة لخصوصية المستهلك

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

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

مخاطر الطرف الثالث وسلسلة التوريد تواصل الظهور في منصات CRM

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

مثال حديث واضح على هذه الديناميكية هو انتهاك سلسلة التوريد لـLastPass عبر Klue، حيث اخترق المهاجمون بائعًا من أطراف ثالثة واستخدموا رموز OAuth المسروقة للوصول إلى بيئة Salesforce الخاصة بـLastPass. يشير كل من تلك الحادثة وتعرّض Salesforce/ServiceNow لمدة 17 شهرًا إلى المشكلة الهيكلية نفسها: منصات CRM للمؤسسات تقع عند تقاطع تدفقات بيانات العديد من الشركات، وحلقة ضعيفة واحدة، سواء كانت إعدادًا خاطئًا أو ثغرة غير مُصلحة أو تكامل بائع مخترق، يمكن أن تكشف معلومات تتجاوز بكثير المؤسسة التي تملك البوابة.

ما الذي يعنيه هذا بالنسبة لك

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

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

خلاصات قابلة للتنفيذ

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

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