ملخص
- أفادت مجموعة استخبارات التهديدات من Google أنه في الفترة من 8 أغسطس وحتى 18 أغسطس 2025 على الأقل، استهدفت المجموعة المعروفة بـUNC6395 مثيلات عملاء Salesforce باستخدام رموز OAuth مخترقة مرتبطة بتطبيق الطرف الثالث Salesloft Drift.
- ذكرت استشارة الثقة من Salesforce أن Salesloft، بالتعاون مع Salesforce، ألغت صلاحية رموز الوصول والتحديث النشطة وأزالت Drift من متجر التطبيقات AppExchange؛ ولم يكن المشكل ناتجًا عن ثغرة في منصة Salesforce الأساسية.
- ذكر مركز الثقة التابع لـSalesloft لاحقًا أن شركة Mandiant حققت في اختراق مشتبه به أثر على منتج Drift، وأن التحقيق قيم السبب الجذري والنطاق والاحتواء والمعالجة والفصل بين تطبيقي Drift وSalesloft.
- يظهر الحادث أن موافقة OAuth ليست خلفية إدارية. يمكن أن يصبح التكامل ذو الصلاحيات الواسعة مسار وصول إلى بيانات CRM للعملاء وحالات الدعم وبيانات الاعتماد المضمنة في السجلات وأنظمة السحابة النهائية.
- المساءلة تتبع السيطرة. سيطرت Salesloft على منتج Drift وحضانة الرمز. سيطرت Salesforce على حوكمة التطبيقات المتصلة للمنصة واستجابة AppExchange وقنوات إعلام العملاء ورؤية التدقيق وإلغاء الرمز الطارئ. تحكم العملاء في موافقات التطبيقات المتصلة ونظافة البيانات، ولكن غالبًا بعد أن جعلت المنصة والبائع التكامل متاحًا.
الجدول الزمني العام يبدأ بالسلطة المفوضة
تُعد استشارة مجموعة استخبارات التهديدات من Google،سرقة بيانات واسعة النطاق تستهدف مثيلات Salesforce عبر Salesloft Drift، المصدر التقني الرئيسي. قالت GTIG أنه بدءًا من 8 أغسطس 2025 وحتى 18 أغسطس 2025 على الأقل، استهدف الفاعل الذي يُتتبع باسم UNC6395 مثيلات عملاء Salesforce من خلال رموز OAuth مخترقة مرتبطة بتطبيق الطرف الثالث Salesloft Drift. وأضافت GTIG أن الفاعل قام بتصدير كميات كبيرة من البيانات من العديد من مثيلات Salesforce المؤسسية وبحث عن أسرار مثل مفاتيح الوصول إلى AWS وكلمات المرور ورموز Snowflake.
أصدرت Salesforceاستشارة أمنيةخاصة بها حددت حدود المنصة. قالت Salesforce أن الحادث تضمن تطبيق Drift الذي نشرته Salesloft، وأن Salesloft بالتعاون مع Salesforce ألغت صلاحية رموز الوصول والتحديث النشطة، وأنه تمت إزالة Drift من AppExchange. كما ذكرت الاستشارة أن المشكلة لم تنشأ من ثغرة في منصة Salesforce الأساسية. هذا البيان مهم ويجب الحفاظ عليه. الحادث ليس دليلاً على أن المهاجمين استغلوا ثغرة في برنامج Salesforce الأساسي.
وصفمركز الثقةالتابع لـSalesloft لاحقًا تحقيق Mandiant في اختراق مشتبه به أثر على منتج Drift. وذكر أن Mandiant تم تكليفها في 26 أغسطس 2025 لتحديد السبب الجذري والنطاق، والمساعدة في الاحتواء والمعالجة، والتحقق من الفصل بين تطبيقي Drift وSalesloft. هذا المصدر مهم لأنه يضع التحقيق على مستوى البائع، وليس فقط على مستوى منصة Salesforce.
تسلسل الاستجابة العامة مهم. تصف Google وSalesforce النشاط في أوائل إلى منتصف أغسطس. تقول استشارة Salesforce أنه تم إلغاء صلاحية الرموز وإزالة Drift من AppExchange.تحليل AppOmni لاختراق Drift-Salesforceيسجل بالمثل أن Salesloft وSalesforce ألغتا رموز OAuth الخاصة بـDrift وأن المنظمات المتأثرة تم إخطارها مباشرة من قبل Salesforce.موجز التهديداتمن وحدة 42 يتتبع الحملة على أنها استخدام رموز OAuth مخترقة لسرقة البيانات من بيئات Salesforce المتأثرة.
حقيقة المساءلة الحاسمة هي السلطة المفوضة. يتيح OAuth للمستخدم أو المسؤول منح التطبيق حق الوصول إلى البيانات والإجراءات دون مشاركة كلمة المرور الخاصة بالمستخدم. هذا التصميم ضروري لـSaaS الحديثة. ولكنه خطير عندما يكون لتطبيق طرف ثالث نطاقات واسعة ورموز تحديث طويلة الأجل وحضانة رمز ضعيفة ووصول إلى بيانات CRM عالية القيمة. يصبح الرمز هو السلطة.
لم تكن هذه سرقة كلمة مرور عادية
لا تزال العديد من خطط التعامل مع الاختراقات تفترض وجود تسجيل دخول بشري. إعادة تعيين كلمة المرور، إضافة المصادقة متعددة العوامل، مراجعة سجل تسجيل الدخول، والمتابعة. تظهر حملة Drift لماذا هذا غير كاف. رمز OAuth ليس مثل كتابة المستخدم لكلمة المرور. يمكن أن يمثل تطبيقًا موثوقًا به لديه بالفعل موافقة على الوصول إلى البيانات. يمكنه تجاوز بعض ضوابط تسجيل الدخول البشرية لأنه من المتوقع أن يستدعي التطبيق واجهات برمجة التطبيقات دون وجود شخص.
هذا لا يعني أن المصادقة متعددة العوامل غير ذات صلة. يمكن للمصادقة متعددة العوامل منع اختراق المستخدم الأولي ويمكنها حماية سير عمل الموافقة الإدارية. ولكن بعد وجود رمز تطبيق صالح، تصبح الضوابط المهمة هي نطاقات التطبيق وتخزين الرمز وعمر رمز التحديث ومراجعة التطبيق وسرعة الإلغاء ومراقبة واجهة برمجة التطبيقات واكتشاف الحالات الشاذة في الوصول إلى البيانات. يمكن أن يكون لدى العميل مصادقة متعددة العوامل بشرية جيدة ومع ذلك يكون عرضة للخطر إذا تمت سرقة رمز تطبيق طرف ثالث.
حذرت استشارة FBI وIC3 TLP:CLEAR،جماعات الجرائم الإلكترونية UNC6040 وUNC6395 تخترق منصات Salesforce، من أن UNC6395 استخدمت رموز OAuth مخترقة لتطبيق Salesloft Drift وأن آلية الوصول اختلفت عن الحملات الأخرى التي تستهدف Salesforce.تنبيه الأمن السيبراني الصادر عن FINRA بشأن هجوم سلسلة التوريد AI لـSalesloft Driftصاغ الحادث للشركات المالية الخاضعة للتنظيم، قائلاً أن رموز مصادقة OAuth المسروقة سمحت للجهات الفاعلة التهديدية بانتحال شخصية تطبيق Drift الموثوق به والحصول على وصول غير مصرح به إلى بيئات العملاء.
يظهر هذان التحذيران لماذا كانت هذه قضية حوكمة، وليس مجرد اختراق بائع. كان على الشركات الخاضعة للتنظيم فحص ما إذا كان تطبيق طرف ثالث لديه حق الوصول إلى بيانات Salesforce، وما إذا كانت الأسرار مخزنة في سجلات CRM، وما إذا كان العملاء أو العملاء المحتملون قد تعرضوا. أصبحت مشكلة المنصة والبائع مشكلة امتثال للعميل.
وثائق Salesforce حول التطبيقات المتصلةتصف النموذج الأساسي لتكامل التطبيقات الخارجية مع Salesforce.وثائق OAuth للتطبيقات المتصلة، بما في ذلك إعدادات OAuth، توضح لماذا النطاقات والسياسات مهمة. هذه المستندات ليست أدلة على الحادث. إنها تشرح سطح التحكم.
النطاقات حولت الثقة إلى نصف قطر انفجار
تحدد نطاقات OAuth ما يمكن للتطبيق فعله. في تصميم ضيق، يحصل التطبيق فقط على الوصول اللازم لمهمة محددة. في تصميم واسع، يمكنه قراءة أو كتابة فئات كبيرة من السجلات، استدعاء واجهات برمجة التطبيقات، تحديث الوصول، والعمل عبر سطح بيانات واسع. تطرح حملة Drift السؤال: هل تفوقت راحة التكامل على انضباط النطاق؟
أبلغت GTIG أن UNC6395 استفسرت بشكل منهجي عن البيانات من بيئات Salesforce وصدرتها وبحثت في السجلات عن بيانات الاعتماد. هذا يعني أن التعرض لم يقتصر على قائمة الحقول المملوكة لـSalesloft. لقد شمل بيانات عملاء Salesforce التي يمكن الوصول إليها من خلال التكامل. إذا كان لدى العميل أسرار في حالات Salesforce، أو ملاحظات، أو سلاسل محادثات دعم، أو نصوص دردشة، أو حقول مخصصة، أو مرفقات، يمكن أن تصبح تلك الأسرار المرحلة التالية من المخاطر.
هذا فرق رئيسي عن اختراق جدول العملاء الخاص بالبائع. سمح الرمز المخترق للمهاجم بالوصول إلى بيئة Salesforce لكل عميل متصل. يعتمد الضرر على ما يخزنه كل عميل، وكيفية تكوين مؤسسة Salesforce الخاصة به، والكائنات التي يمكن للتطبيق الوصول إليها، وما إذا كانت الأسرار مضمنة في السجلات. يمكن لنفس فئة الرمز المسروق أن تنتج أضرارًا مختلفة عبر العملاء.
ركز تحليل AppOmni على الوقاية من SaaS إلى SaaS وصعوبة الرؤية عبر التطبيقات المتصلة.النشرة الأمنيةلـArctic Wolf صاغت الحدث بالمثل حول رموز OAuth المخترقة لـSalesloft Drift وسرقة بيانات Salesforce. هذه المصادر هي تحليلات بائعة، لكنها تعزز نفس نقطة التحكم: تكاملات SaaS تخلق هويات غير بشرية تستحق حوكمة دورة الحياة.
مصطلح "هوية غير بشرية" قد يبدو مجردًا. في هذا الحادث، يعني بيانات اعتماد تطبيق يمكنها التصرف دون وجود إنسان على لوحة المفاتيح. قد تتم الموافقة عليها مرة واحدة ثم تستمر. قد يكون لها وصول واسع لأن الوصول الواسع يجعل التكامل مفيدًا. قد لا تظهر في لوحات معلومات تسجيل الدخول العادية للمستخدم. قد تعمر أكثر من عملية العمل التي بررت وجودها. بمجرد سرقتها، يمكنها التحرك بسرعة لأن استدعاءات واجهة برمجة التطبيقات طبيعية لتلك الهوية.
سوق التطبيقات المتصلة جزء من سلسلة التحكم
ذكرت استشارة Salesforce أنه تمت إزالة Drift من AppExchange pending مزيد من التحقيق. هذه الاستجابة مهمة لأن AppExchange ليس مجرد دليل. إنه إشارة ثقة. غالبًا ما يستنتج العملاء أن التطبيقات المدرجة في السوق قد اجتازت عملية مراجعة ومناسبة للتثبيت. السوق لا يلغي العناية الواجبة للعميل، لكنه يؤثر على اختيارات العميل.
عندما يصبح تطبيق السوق مسار وصول للحملة، فإن مسؤولية المنصة ليست أنها تسببت في اختراق البائع. المسؤولية هي أنها يجب أن تكتشف وتتواصل وتعطل وتساعد العملاء على التعافي أسرع مما يسمح به الاكتشاف عميلاً بعميل. ترى المنصة تثبيتات التطبيق عبر المستأجرين. يمكنها تحديد العملاء الذين قاموا بتثبيت التطبيق. يمكنها تنسيق إلغاء الرمز. يمكنها إخطار العملاء المتأثرين. يمكنها إزالة أو تعليق القائمة. رؤية العملاء المتعددين هذه هي بالضبط لماذا حوكمة المنصة مهمة.
يبدو أن Salesforce استخدمت دور المنصة هذا في السجل العام: ذكرت استشارتها أنها عملت مع Salesloft، وألغت صلاحية الرموز، وأزالت التطبيق، وأخطأت المنظمات المتأثرة. سؤال المساءلة هو مدى سرعة حدوث ذلك بالنسبة لأول نشاط مشبوه وما إذا كان لدى العملاء وصول كافٍ إلى السجلات لتحديد تعرضهم. أبلغت GTIG عن نشاط الحملة بدءًا من 8 أغسطس؛ تم الإبلاغ عن إلغاء الرمز في 20 أغسطس. يمكن للجمهور رؤية الفاصل الزمني التقريبي، ولكن ليس عملية اتخاذ القرار الداخلي للكشف.
العميل لديه أيضًا مسؤوليات. يختارون التطبيقات، يوافقون على النطاقات، يخزنون الأسرار في السجلات، يراقبون سلوك واجهة برمجة التطبيقات، ويراجعون التطبيقات المتصلة. لكن مسؤولية العميل محدودة بإمكانيات المنصة. إذا كانت مراجعات التطبيقات المتصلة صعبة الفهم، أو إذا كانت النطاقات خشنة جدًا، أو إذا كان من الصعب الوصول إلى السجلات، أو إذا كان مخزون الرموز مجزأً، أو إذا كانت ثقة السوق غامضة، يتخذ العملاء قرارات برؤية غير كاملة.
لذلك لا ينبغي تأطير الحادث كتمرين بسيط لإلقاء اللوم على ثلاثة أطراف. إنها سلسلة: كان على Salesloft حماية Drift ورموزه؛ كان على Salesforce حوكمة ثقة التطبيقات المتصلة والإلغاء الطارئ؛ كان على العملاء تقييد وصول التطبيق وإزالة الأسرار من بيانات CRM؛ استغل المهاجمون السلسلة.
أصبحت بيانات CRM سطحًا لصيد الأسرار
أكثر النتائج إثارة للقلق من GTIG ليست مجرد أن سجلات CRM تم تصديرها. بل أن الفاعل بحث عن الأسرار. قد تحتوي بيئة Salesforce على حالات دعم، ملاحظات مبيعات، تفاصيل تأهيل العملاء، سلاسل استكشاف الأخطاء التقنية، مفاتيح API ملصقة في التذاكر، نقاط نهاية VPN، معرفات حسابات سحابية، بيانات اعتماد تكامل، كلمات مرور مخزنة عن طريق الخطأ في تعليقات الحالة، أو مرفقات تحتوي على بيانات تشغيلية حساسة. لا ينبغي أن تكون هذه المواد في سجلات CRM، لكنها غالبًا ما تكون في المنظمات الحقيقية.
هذا يحول الضرر من الخصوصية إلى المخاطر الجانبية. إذا استخدم المهاجم تصدير CRM للعثور على مفاتيح AWS أو رموز Snowflake أو بيانات اعتماد VPN أو أسرار أخرى، يمكن أن ينتقل الاختراق من تعرض بيانات العميل إلى اختراق البنية التحتية. يصبح نظام CRM خريطة للأنظمة الأخرى. إنه المكان حيث توثق فرق الدعم المشكلات، وقد تتضمن هذه التوثيقات القرائن اللازمة لمهاجمة الأنظمة التي يتم دعمها.
تقول استشارة GTIG العامة أن المنظمات يجب أن تبحث عن الأسرار وتدوير بيانات الاعتماد. هذه النصيحة مكلفة تشغيليًا لأنه يتعين على العملاء البحث في بياناتهم الخاصة عن مواد لم يكن ينبغي لهم تخزينها هناك أبدًا. وبالتالي يكشف الحادث عن فشل في نظافة البيانات على مستوى العميل. لكن المحفز كان اختراق تكامل موثوق به. قد لا يكون العملاء أدركوا أن روبوت الدردشة أو تكامل سير عمل الإيرادات يمكنه الوصول إلى سجلات تحتوي على بيانات اعتماد.
يمكن لـ Salesforce والعملاء تقليل هذه المخاطر من خلال معاملة فحص الأسرار كعنصر تحكم في CRM. يجب فحص السجلات بحثًا عن أنماط المفاتيح. يجب أن تثبط سير عمل الدعم لصق كلمات المرور أو الرموز. يجب إخفاء الحقول الحساسة. لا ينبغي أن تتضمن نطاقات التطبيق كائنات غير ضرورية. يجب مراقبة الصادرات. هذه ليست ضوابط غريبة؛ إنها استجابات عملية لواقع أن أنظمة CRM تحتوي على بيانات تشغيلية فوضوية.
يشرح الخطر أيضًا لماذا إخطار العملاء مهم. إذا تأثرت منظمة عميل، يحتاج فريق الأمن التابع لها إلى معرفة ذلك بسرعة كافية لفحص السجلات، وتدوير الأسرار المكشوفة، والتحقق من سجلات السحابة النهائية، وتحذير عملائها حيثما لزم الأمر. يمكن أن يسمح إشعار متأخر أو غامض ببقاء الأسرار المسروقة صالحة.
كان إلغاء الرمز ضروريًا، لكنه لم يكن التعافي بحد ذاته
إلغاء الرمز يغلق مسار الوصول المفوض الفوري. تصف كل من استشارة Salesforce وGTIG إلغاء أو إبطال رموز الوصول والتحديث لـDrift. كان ذلك ضروريًا. لم يقم، بحد ذاته، بإزالة البيانات التي تم تصديرها بالفعل أو الأسرار التي تم جمعها بالفعل. كان على التعافي أن يستمر داخل بيئات العملاء.
الخطوة الأولى للتعافي هي تحديد نطاق التعرض: أي كائنات Salesforce تم الوصول إليها، وأي السجلات تم الاستعلام عنها، وأي وظائف API تم تشغيلها، وأي تكاملات تم استخدامها؟ يمكن أن تكونوثائق مراقبة الأحداث وأمان المعاملاتوسجلات API من Salesforce مهمة هنا، لكن توفر السجل يختلف حسب الإصدار والتكوين والاحتفاظ ونضج العميل. لا يمكن للاستشارات العامة أن تحل محل الأدلة على مستوى المستأجر.
الخطوة الثانية هي تدوير الأسرار. إذا كانت السجلات تحتوي على مفاتيح AWS أو رموز Snowflake أو بيانات اعتماد VPN أو مفاتيح API أو كلمات مرور أو أسرار webhook، فيجب العثور على تلك الأسرار وتدويرها. هذا صعب لأن الأسرار قد تكون في حقول نص حر أو مرفقات أو تعليقات حالة أو سجلات دردشة أو كائنات مخصصة. يساعد البحث الآلي، لكنه قد يفوت التنسيقات غير المعتادة. المراجعة اليدوية بطيئة.
الخطوة الثالثة هي إخطار العملاء والأطراف النهائية. قد يكون لدى عميل Salesforce الذي تم تصدير بيانات CRM منه التزامات تجاه عملائه وموظفيه وعملائه المحتملين وشركائه والجهات التنظيمية. هذا يخلق سلسلة متتالية. أصبح حادث Salesloft حادث منصة Salesforce، والذي أصبح حادث كل عميل متأثر، والذي قد يصبح إشعار عميل لكل عميل متأثر. تنتقل تكلفة اختراق OAuth واحد إلى الخارج.
الخطوة الرابعة هي مراجعة حوكمة التطبيق. يحتاج العملاء إلى السؤال عن التطبيقات المتصلة الأخرى التي لديها نطاقات مماثلة، وما إذا كانت لا تزال ضرورية، وما إذا كانت رموز التحديث طويلة الأجل، وما إذا كان مالكو التطبيقات معروفين، وما إذا كانت مراجعات مخاطر البائع حديثة، وما إذا كانت خطط الإلغاء الطارئ موجودة. يجب معاملة حادث Drift كبروفة لكل تكامل SaaS آخر ذي صلاحيات عميقة.
لم تغير العلامة التجارية للذكاء الاصطناعي مشكلة المساءلة
بعض المناقشات العامة صاغت Drift كتكامل روبوت دردشة ذكاء اصطناعي. هذا مهم لسياق المنتج، لكن فشل الأمن لم يكن سحريًا بسبب الذكاء الاصطناعي. القضية الرئيسية كانت الوصول المفوض إلى SaaS. يمكن لروبوت الدردشة، أداة مشاركة المبيعات، أداة الدعم، موصل التحليلات، أداة إثراء البيانات، أو منصة أتمتة التسويق أن تصبح جميعها خطيرة إذا كانت تحمل رموزًا واسعة إلى أنظمة العملاء.
قد يزيد الذكاء الاصطناعي من الشهية للتكاملات لأن الشركات تريد أدوات المحادثة لرؤية المزيد من السياق. روبوت دردشة المبيعات أو الدعم يكون أكثر فائدة إذا كان يمكنه قراءة سجلات CRM، الإجابة على أسئلة العملاء، تحديث الحالات، توجيه العملاء المحتملين، وتخصيص الاستجابات. كل نطاق إضافي يزيد من الفائدة والمخاطر. إذا تمت سرقة الرمز وراء هذا النطاق، يتلقى المهاجم نفس السياق الواسع الذي جعل المنتج جذابًا.
هذا هو اقتصاد أمان أتمتة SaaS. يبيع البائعون سير عمل أكثر سلاسة. يوافق العملاء على الوصول لأن سير العمل يوفر العمالة. تستضيف المنصات نموذج الإذن لأن التكاملات توسع قيمة النظام البيئي. الخطر هو أن أيًا من الأطراف لا يسعر بالكامل تكلفة اختراق الرمز حتى بعد حملة. حادث Drift هو دراسة حالة في ذلك الخطر غير المسعر.
تنبيه FINRA مهم لأن الشركات المالية الخاضعة للتنظيم لا يمكنها معاملة هذا كقصة إخبارية تقنية عامة. إذا استخدمت شركة مالية Drift مع Salesforce، كان عليها تقييم ما إذا كانت بيانات العميل أو العميل المحتمل أو البيانات الداخلية قد تعرضت وما إذا كانت بيانات الاعتماد في سجلات CRM خلقت مخاطر نهائية. ينطبق نفس المنطق في الرعاية الصحية والتعليم والبرمجيات والتعاقد مع القطاع العام وأي قطاع حيث يحتوي Salesforce على سياق تشغيلي حساس.
كشف الحادث عن عدم تماثل في الرؤية
ترى المنصات أنماطًا لا يستطيع العملاء الأفراد رؤيتها. قد يلاحظ عميل واحد سلوك API غريبًا في مؤسسة Salesforce الخاصة به. تستطيع Salesforce رؤية تثبيتات تطبيقات AppExchange، وإلغاءات الرموز، والأنماط عبر العملاء. تستطيع Salesloft رؤية تلميترى منتج Drift وحضانة الرمز. يمكن لمجموعة استخبارات التهديدات من Google رؤية نشاط التهديد عبر العملاء وتحقيقاتها الخاصة. لا يمكن لأي عميل واحد رؤية الحملة بأكملها.
هذا التباين يخلق واجبات. يجب على الطرف الذي لديه رؤية عبر العملاء أن يحذر بسرعة. يجب على الطرف الذي لديه تلميترى المنتج أن يحقق ويحتوي بسرعة. يجب على المنصة المساعدة في تحديد العملاء المتأثرين. يجب على العملاء التصرف بسرعة بمجرد إخطارهم. إذا انتظر أي طرف للحصول على أدلة كاملة، يمكن للمهاجم الاستمرار في استخدام السلطة الصالحة.
يشير السجل العام إلى إجراء منسق، ولكن ليس السرعة الدقيقة للتصعيد الداخلي. قالت GTIG أن الحملة بدأت في 8 أغسطس. أبلغت استشارة Salesforce عن إجراءات الإلغاء والإزالة. يقول مركز الثقة لـSalesloft أنه تم تكليف Mandiant في 26 أغسطس. تظهر هذه التواريخ الحركة، لكنها لا تظهر متى عرف كل طرف ما يكفي للتصرف أو ما هي الإشارات التي كانت متاحة سابقًا.
هذا الخط الزمني المفقود مهم لأن حملات OAuth سريعة. بمجرد سرقة الرموز، يمكن للمهاجم أتمتة الاستعلامات والتصدير. يمكن أن يحدد فرق الأيام ما إذا كان العملاء يدورون الأسرار قبل الاستخدام أو بعده. سيظهر تحليل ما بعد الحادث عالي الجودة وقت الكشف، وقت القرار، وقت إلغاء الرمز، وقت إخطار العميل، ووقت توفر السجل.
ما يجب أن يتعلمه العملاء دون أن يتم لومهم
العملاء لديهم مسؤوليات، لكن لا ينبغي أن يصبح الدرس "كان ينبغي على العملاء أن يعرفوا أفضل." العديد من العملاء يقومون بتثبيت تطبيقات السوق لأنهم يعتمدون على إشارات ثقة المنصة. يوافقون على النطاقات لأن البائعين يقولون أن النطاقات ضرورية. يخزنون البيانات التشغيلية في CRM لأن الموظفين يستخدمون CRM كذاكرة مشتركة لعمل العميل. هذه سلوكيات تجارية عادية، وليست أفعالًا متهورة بشكل افتراضي.
الدرس الأفضل هو حوكمة التطبيقات المتصلة المنضبطة. يجب على العملاء جرد التطبيقات المتصلة، والمالكين، والنطاقات، وأعمار الرموز، وتواريخ آخر استخدام، وحالة مخاطر البائع. يجب عليهم إزالة التطبيقات التي لم تعد ضرورية. يجب عليهم تقييد الملفات الشخصية ومجموعات الأذونات المتاحة للتطبيقات. يجب عليهم فحص بيانات CRM بحثًا عن الأسرار. يجب عليهم مراقبة سلوك API حسب التطبيق، وليس فقط حسب المستخدم. يجب أن يكون لديهم دليل إجراءات للإلغاء الطارئ للرمز.
يمكن لـ Salesforce أن تجعل مسؤوليات العميل هذه أسهل أو أصعب. تفسيرات واضحة لأذونات التطبيق، وتسجيل مخاطر التطبيق، وتحذيرات المسؤول للنطاقات الواسعة، ومخزون الرموز البسيط، وانتهاء صلاحية افتراضي أفضل، وتنبيهات الحالات الشاذة، ومراجعة قوية لـ AppExchange يمكن أن تقلل من عبء العميل. يشكل تصميم المنصة سلوك العميل.
يمكن لـ Salesloft وبائعي SaaS الآخرين أيضًا تقليل العبء عن طريق تخزين الرموز بشكل آمن، وتقليل النطاقات المطلوبة، وتدوير بيانات الاعتماد، ونشر تحديثات الحادث بسرعة، وإثبات الفصل. إشارة مركز الثقة لـSalesloft إلى التحقق من الفصل بين تطبيقي Drift وSalesloft مهمة لأن العملاء بحاجة إلى الثقة بأن اختراق منتج واحد لم يصبح اختراقًا أوسع للبائع.
معايير OAuth تفسر لماذا تتطلب رموز الحامل انضباطًا إضافيًا
تم تصميم OAuth للتفويض المفوض.RFC 6749، المواصفات الأساسية لـOAuth 2.0، تسمح للعميل بالحصول على رموز وصول إلى الموارد بتفويض من مالك المورد. التصميم قوي لأن المستخدم لا يحتاج إلى إعطاء العميل كلمة المرور الخاصة به. الخطر هو أن رمز الوصول غالبًا ما يكون شهادة حامل: من يملكه يمكنه استخدامه ضمن نطاقه حتى ينتهي صلاحيته أو يتم إلغاؤه.
RFC 6819، نموذج تهديد OAuth واعتبارات الأمان، يحذر من تسرب الرمز، وتخزين الرمز، وإعادة التشغيل، والتصيد، وإساءة استخدام إعادة التوجيه، والحاجة إلى الحد من النطاق والعمر.RFC 9700، أفضل الممارسات الأمنية الحالية لـOAuth 2.0، يواصل هذا الاتجاه من خلال التركيز على أنماط الدفاع الحديثة. هذه المعايير ليست تقارير عن حوادث Salesforce. إنها تشرح لماذا كانت حملة Drift خطيرة من الناحية الهيكلية.
إذا كان لرمز Drift وصول واسع إلى Salesforce، فإن الرمز نفسه جسد الثقة. يمكن لفريق الأمن إزالة كلمة مرور المستخدم، وفرض المصادقة متعددة العوامل، وما زال يواجه خطرًا إذا ظل رمز التطبيق صالحًا. لهذا السبب كان إلغاء الرمز هو الإجراء الطارئ. وهو أيضًا لماذا الطبقة التالية هي تقليل النطاق. رمز مسروق بنطاق ضيق يمكن أن يكون ضارًا ولكنه مقيد. رمز مسروق مع وصول قراءة واسع يمكن أن يصبح أداة تصدير بيانات.
تقنية MITRE ATT&CK لسرقة رمز وصول التطبيقتصف الخصوم الذين يسرقون رموز وصول التطبيق للوصول إلى الأنظمة البعيدة وواجهات برمجة التطبيقات.تقنيتها لاستخدام مواد مصادقة بديلةتغطي النمط الأوسع لاستخدام قطع المصادقة الصالحة بدلاً من كلمات المرور. تساعد هذه الأطر في تسمية فئة الهجوم دون المبالغة في الحقائق الخاصة بـSalesforce: المشكلة كانت مواد مفوضة صالحة في الأيدي الخطأ.
الدرس المعياري بسيط لكنه صعب تشغيليًا. يجب معاملة الرموز كأسرار. يجب معاملة رموز التحديث كأسرار حساسة بشكل خاص لأنها يمكن أن تصدر وصولاً مستقبليًا. يجب أن تكون النطاقات ضيقة قدر ما يمكن للمنتج تحمله. يجب تدوير الرموز وجعلها قابلة للإلغاء. يجب أن تظهر السجلات استخدام الرمز حسب التطبيق وحسب الكائن. يجب أن يعرف العملاء أي الهويات غير البشرية يمكنها قراءة بياناتهم. يجب على المنصات أن تجعل النطاقات الخطرة صعبة الموافقة عليها بصمت.
نظافة التطبيقات المتصلة تحتاج إلى مالك، وليس جدول بيانات بعد الاختراق
تكتشف العديد من المنظمات تطبيقاتها المتصلة أثناء الحادث. هذا متأخر جدًا. يجب أن يوجد مخزون التطبيقات المتصلة قبل الحملة: اسم التطبيق، البائع، المالك التجاري، المالك التقني، النطاقات، الملفات الشخصية المثبتة، آخر استخدام، سياسة رمز التحديث، كائنات البيانات التي تم لمسها، حالة العقد، وإجراءات الإزالة. إذا لم يملك أحد التطبيق، فلا أحد يملك المخاطرة.
وثائق Salesforce لإدارة التطبيقات المتصلةوسياسات OAuth للتطبيقات المتصلةتظهر أن المنصة تقدم ضوابط إدارية. السؤال هو ما إذا كان لدى العملاء الموظفين والمعرفة والحوافز لاستخدامها بشكل جيد. قد تقوم شركة صغيرة بتثبيت أداة دردشة مبيعات ولا تعود أبدًا إلى نطاقاتها. قد يكون لدى مؤسسة كبيرة مئات التطبيقات المتصلة ولا وتيرة مراجعة موحدة.
هذا هو المكان الذي يجب أن يقلل فيه تصميم المنصة من الأخطاء. يجب أن تكون النطاقات الخطرة مرئية بلغة واضحة. يجب أن يكون من السهل العثور على التطبيقات المتصلة غير المستخدمة. يجب تسليط الضوء على التطبيقات التي تحتوي على رموز تحديث. يجب أن يكون للتطبيقات عالية المخاطر خيارات انتهاء صلاحية أو إعادة تفويض دورية. يجب أن يكون المسؤولون قادرين على إلغاء وصول التطبيق دون كسر سير العمل غير المرتبط. يجب أن تتلقى فرق الأمن تنبيهات API خاصة بالتطبيق.
يحتاج العملاء أيضًا إلى سياسة. لا ينبغي لأي تطبيق أن يحصل على وصول واسع بدون مالك مسمى وتاريخ مراجعة. لا ينبغي لأي تطبيق أن يبقى مثبتًا بعد مغادرة المالك التجاري. لا ينبغي لأي تطبيق أن يخزن أسرارًا في سجلات CRM لمجرد أنها مريحة. لا ينبغي لأي تطبيق أن يكون معفيًا من خطط الحوادث لأنه "مجرد أداة مبيعات." أظهرت حملة Drift أن أداة المبيعات يمكن أن تصبح مسار حادث أمني.
المشكلة اقتصادية جزئيًا. التطبيقات المتصلة توفر العمالة. المراجعة تكلف العمالة. إذا كانت الفائدة فورية والمخاطرة نادرة، فإن المنظمات تستثمر أقل في المراجعة. يمكن للمنصة والبائع تقليل هذا الخلل عن طريق خفض تكلفة الحوكمة الجيدة: لوحات معلومات واضحة، درجات مخاطر، توصيات آلية، وإعدادات افتراضية أكثر أمانًا.
يجب أن تجيب السجلات على الأسئلة التي يمكن للعميل التصرف بناءً عليها
غالبًا ما يخبر توجيه الحوادث العملاء بمراجعة السجلات. هذه النصيحة مفيدة فقط إذا كانت السجلات تجيب على الأسئلة الصحيحة. بالنسبة لحملة Drift، كان العملاء بحاجة إلى معرفة أي رموز التطبيق تم استخدامها، وأي كائنات Salesforce تم الاستعلام عنها، وأي السجلات تم تصديرها، ومن أي عناوين IP، وبأي سياق مستخدم، وعلى مدى أي نافذة زمنية، وما إذا كانت الاستعلامات بحثت عن سلاسل تشبه الأسرار.
يمكن أن تساعد مراقبة أحداث Salesforce وسجلات API وتقارير التطبيقات المتصلة، لكن الوصول إلى الأدلة الكاملة قد يعتمد على الترخيص والاحتفاظ والتكوين. العميل الذي يفتقر إلى الإصدار المناسب أو خط أنابيب تصدير السجل قد يتلقى إشعارًا وما زال يكافح لتحديد التعرض. هذه مشكلة حوكمة منصة. عندما يتم إساءة استخدام تكامل السوق عبر العملاء، تكون المنصة في أفضل وضع لتوفير حزم أدلة موحدة.
يحتاج العملاء أيضًا إلى مسار فرز قابل للتكرار. أولاً، تحديد ما إذا كان Drift مثبتًا ومتصلاً. ثانيًا، تحديد ما إذا كانت الرموز نشطة خلال نافذة الحملة. ثالثًا، فحص نشاط API المنسوب إلى التطبيق. رابعًا، تحديد الوصول إلى الكائن والحقل. خامسًا، البحث في السجلات المصدرة أو القابلة للوصول عن الأسرار. سادسًا، تدوير أي أسرار قد تكون تعرضت. سابعًا، إخطار الأطراف النهائية إذا كانت البيانات الخاضعة للتنظيم أو بيانات العميل متضمنة.
تشير استشارة FBI/IC3 وتوجيه GTIG العملاء نحو هذا النوع من الإجراءات، لكن التنفيذ يختلف على نطاق واسع. قد يكون لدى شركة مالية كبيرة فريق عمليات أمنية وبحيرة سجلات. قد يكون لدى شركة SaaS صغيرة مسؤول Salesforce وبائع أمن مُدار وقائمة متراكمة. وبالتالي نفس الحملة تخلق أعباء تعافي غير متكافئة.
هذا التفاوت مهم للمساءلة. المنصات التي تخدم شركات بمستويات نضج مختلفة جدًا لا ينبغي أن تفترض أن جميع العملاء يمكنهم تفسير السجلات الأولية أو مؤشرات استخبارات التهديدات. الأدلة القابلة للتنفيذ الخاصة بالمستأجر تقلل من تكلفة الاستجابة وفرصة بقاء الأسرار المسروقة صالحة.
الأسرار في سجلات CRM هي فشل يمكن منعه ولكنه شائع
أحد الدروس غير المريحة هو أنه يجب على العملاء التوقف عن معاملة CRM كمكان آمن للأسرار التشغيلية. غالبًا ما تلصق فرق الدعم والمبيعات مفاتيح API وبيانات الاعتماد ورموز الحامل وأسرار webhook وتفاصيل VPN أو لقطات شاشة في الحالات والملاحظات لأنهم يحاولون حل مشكلة. يصبح CRM أرشيفًا للراحة. عندما يمكن للتكامل قراءته، يصبح أرشيف الراحة مستودعًا للأسرار.
ورقة الغش لإدارة الأسرارمن OWASP تشرح لماذا تحتاج الأسرار إلى تخزين خاضع للتحكم وتدوير وانضباط في الوصول. تطبق حملة Drift هذا المبدأ على بيانات CRM. إذا ظهرت الأسرار في السجلات، يمكن أن يصبح تصدير CRM سلسلة مفاتيح.
الإصلاح تقني جزئيًا: فحص السجلات بحثًا عن أنماط الأسرار، إخفاء الحقول الحساسة، تقييد المرفقات، والتنبيه عند ظهور تنسيقات مفاتيح معروفة. وهو ثقافي أيضًا: تدريب فرق الدعم على عدم طلب أو تخزين الأسرار، توفير قنوات استقبال آمنة للمواد التشخيصية الضرورية، وتسهيل تطهير الأسرار عند اكتشافها. إذا كانت المنظمة تعاقب الدعم البطيء ولكن ليس ملاحظات الدعم غير الآمنة، سيستمر الموظفون في أخذ الاختصارات.
يمكن لـ Salesforce وبائعي التكامل المساعدة من خلال بناء ميزات كشف الأسرار وتحذير العملاء عندما تتضمن نطاقات التطبيق الواسعة كائنات من المحتمل أن تحتوي على بيانات تشغيلية حساسة. لكن العملاء ما زالوا يمتلكون نظافة البيانات داخل مؤسساتهم. لم يخلق حادث Drift الممارسة السيئة لتخزين الأسرار في CRM؛ لقد كشف كيف يمكن لهذه الممارسة أن تضخم اختراق رمز طرف ثالث.
يجب أن يحافظ السجل العام على ما لم يحدث
من المهم بنفس القدر ذكر ما لا يظهره السجل العام. لا تظهر المصادر أن المهاجمين استغلوا ثغرة أساسية في Salesforce. لا تظهر أن كل عميل Salesforce تأثر. لا تظهر أن كل عميل متصل بـDrift تم تصدير نفس البيانات له. لا تظهر أن كل سجل تم تصديره احتوى على أسرار. لا تظهر أن مجموعة منتجات Salesloft الأوسع تم اختراقها بما يتجاوز ما وصفه تحقيق Salesloft.
تلك الحدود تحمي العدالة. كما تجعل الدرس الحقيقي أكثر حدة. الحادث خطير دون مبالغة لأن تكاملًا موثوقًا به أصبح مسار وصول مفوض إلى بيئات العملاء. الجاذبية تأتي من نموذج الثقة، وليس من الحاجة لاختراع يوم صفري للمنصة.
لا ينبغي أيضًا اختزال الحادث إلى "مخاطر طرف ثالث" بمعنى غامض. مخاطر الطرف الثالث المحددة كانت حضانة الرمز وسلطة التطبيق المتصل. يمكن أن يكون لدى البائع تقارير SOC وعقود واستبيانات أمنية بينما لا يزال يحمل رموزًا تتطلب حماية استثنائية. تحتاج مراجعات مخاطر البائع من العميل إلى السؤال عن كيفية تخزين تكاملات SaaS للرموز، وما النطاقات التي تتطلبها، ومدى سرعة إلغاء الرموز، وما الأدلة التي يمكن للبائع تقديمها بعد الحادث.
تحتاج مراجعة AppExchange للمنصة أيضًا إلى الخصوصية. لا ينبغي أن تتحقق فقط مما إذا كان التطبيق يعمل ويلبي متطلبات الأمان الأساسية عند وقت الإدراج. يجب أن تدعم المراقبة المستمرة والتعليق السريع وإخطار العملاء وإعادة التحقق بعد الحادث. الثقة في السوق هي التزام مستمر، وليس شارة لمرة واحدة.
ما الأدلة التي من شأنها تغيير التقييم
يمكن أن يتغير التقييم في أي اتجاه مع المزيد من الأدلة. إذا أظهرت التفاصيل الجنائية لاحقًا أن الرموز المخترقة كانت ضيقة للغاية، وأن الصادرات كانت محدودة، وأن العملاء المتأثرين تلقوا سجلات كاملة على مستوى الكائن بسرعة، فيجب تقليل الشدة التشغيلية. إذا أظهرت الأدلة اللاحقة نطاقات أوسع، ورموز طويلة الأجل، وتخزين رمز ضعيف، وإلغاء متأخر، أو تعرض واسع النطاق للأسرار، فيجب أن ترتفع الشدة.
إذا نشرت Salesforce مزيدًا من التفاصيل حول تحسينات مراقبة AppExchange، وميزات مخزون الرموز، وحزم سجلات العملاء، أو إعدادات افتراضية أكثر أمانًا للتطبيقات المتصلة، فإن ذلك سيعزز سجل الإصلاح. إذا نشرت Salesloft مزيدًا من التفاصيل حول السبب الجذري، وحضانة الرمز، والفصل، ومعالجة العملاء، فإن ذلك سيعزز مساءلة البائع. إذا أصدرت الجهات التنظيمية نتائج، فيجب تقييمها بشكل منفصل عن سجل الاستشارات العامة الحالي.
حتى ذلك الحين، تدعم الأدلة استنتاج تحكم عالي الثقة: تحتاج أنظمة SaaS البيئية إلى حوكمة التطبيقات المتصلة التي تعامل الرموز المفوضة كبيانات اعتماد إنتاج، وليس كسباكة تكامل.
هذا الاستنتاج مفيد على وجه التحديد لأنه يتجنب الادعاء الزائد. يسمح للعملاء بتقوية التطبيقات المتصلة دون انتظار سجل محكمة نهائي. يسمح للمنصات بتحسين ضوابط السوق والرمز دون الاعتراف بخلل في المنصة الأساسية لا تظهره الأدلة. يسمح للبائعين بمعاملة حضانة الرمز كالتزام بسلامة المنتج. درس الحملة ليس تخمينيًا: يمكن سرقة الوصول المفوض، وعندما يحدث ذلك، يجب على النظام البيئي أن يعرف من يمكنه إلغاؤه، ومن يمكنه شرحه، ومن يمكنه إثبات ما لمسه.
يجب أن تكون تدريبات الإلغاء روتينية
أسرع طريقة لمعرفة ما إذا كانت حوكمة OAuth حقيقية هي إجراء تدريب إلغاء قبل حادث. اختر تطبيقًا متصلاً غير حاسم. حدد المالك التجاري والنطاقات والمستخدمين والرموز والسجلات وسير العمل التابع ومسار التراجع. ألغ الوصول في نافذة خاضعة للتحكم وقس ما ينكسر. ثم وثق من وافق على الاستعادة وما الأدلة التي أظهرت أن التطبيق كان آمنًا لإعادة الاتصال.
هذا التدريب يحول مخزون التطبيقات المجرد إلى معرفة تشغيلية. يظهر ما إذا كان الأمن يمكنه العثور على التطبيق، وما إذا كان المسؤولون يمكنهم إلغاؤه، وما إذا كانت الأعمال تفهم سير العمل، وما إذا كان المستخدمون يتلقون تعليمات واضحة، وما إذا كانت السجلات يمكنها إثبات ما وصل إليه التطبيق. يكشف أيضًا أين تخشى الفرق لمس التكاملات القديمة لأن لا أحد يعرف لماذا توجد.
تظهر حملة Drift لماذا هذه الممارسة مهمة. في اختراق حقيقي، لا يمكن للمنظمة قضاء أيام في اكتشاف من يمتلك تكاملًا بينما يستخدم المهاجمون الرموز المسروقة. العميل المستعد يمكنه الإلغاء أولاً، والتحقيق بسرعة، وإعادة الاتصال فقط بالأدلة. العميل غير المستعد قد يتردد لأن كل رمز يبدو وكأنه استمرارية أعمال.
اختبار المساءلة
يجب الحكم على حملة Drift-Salesforce من خلال سبعة ضوابط.
أولاً، حضانة الرمز: هل قامت Salesloft بحماية رموز الوصول والتحديث كبيانات اعتماد عالية الحساسية، وهل قللت هندستها من تعرض الرمز عبر Drift والمنتجات الأخرى؟
ثانيًا، تصميم النطاق: هل طلب تكامل Drift فقط أذونات Salesforce التي يحتاجها، وهل فهم العملاء نصف قطر انفجار الموافقة على تلك الأذونات؟
ثالثًا، حوكمة السوق: هل أدت مراجعة AppExchange من Salesforce والمراقبة وعملية الإزالة الطارئة إلى تقليل مخاطر العميل بسرعة كافية بمجرد أن أصبح تطبيق البائع غير آمن؟
رابعًا، الكشف عبر العملاء: هل حددت Salesforce وSalesloft وشركاء استخبارات التهديدات أنماط الحملة بسرعة كافية لإلغاء الرموز قبل المزيد من الصادرات؟
خامسًا، أدلة المستأجر: هل تلقى العملاء المتأثرون ما يكفي من السجلات وأدلة الوصول إلى الكائنات والتوجيه لتحديد ما تم الاستعلام عنه وما إذا كانت الأسرار قد تعرضت؟
سادسًا، نظافة الأسرار: هل خزن العملاء كلمات المرور ومفاتيح API ورموز السحابة أو بيانات اعتماد VPN في سجلات Salesforce، وهل قاموا بتدويرها بعد التعرض؟
سابعًا، الاتصال العام: هل حافظت الاستشارات على التمييز الحاسم بأن Salesforce الأساسية لم يتم استغلالها مع توضيح أن بيانات عملاء Salesforce تم الوصول إليها من خلال رموز التطبيق الموثوقة؟
الاستنتاج النهائي ليس أن Salesforce كان المنتج الضعيف. يقول السجل العام العكس: المشكلة لم تنشأ من ثغرة في منصة Salesforce الأساسية. الاستنتاج هو أن حدود الثقة لـSalesforce تشمل التطبيقات المتصلة لأن العملاء يختبرون المنصة من خلال نظامها البيئي. رموز OAuth هي سلطة مفوضة. عندما يفقد تكامل موثوق به تلك السلطة، يكون للمنصة والبائع والعميل واجبات متميزة. جعلت حملة Drift تلك الواجبات مرئية بأكثر الطرق إزعاجًا: عن طريق تحويل تكامل إنتاجية معتمد إلى مفتاح يحمله المهاجم.