الملخص
- أفادت مجموعة استخبارات التهديدات من 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. وتتابعالموجز التهديديلـ Unit 42 الحملة على أنها بيانات اعتماد OAuth مخترقة تُستخدم لاستخراج البيانات من بيئات Salesforce المتضررة.
الحقيقة الحاسمة للمساءلة هي السلطة المفوضة. تسمح OAuth للمستخدم أو المسؤول بمنح تطبيق حق الوصول إلى البيانات والإجراءات دون مشاركة كلمة مرور المستخدم. هذا التصميم ضروري لـ SaaS الحديثة. كما أنه خطير عندما يكون لتطبيق طرف ثالث نطاقات واسعة، ورموز تحديث طويلة الأجل، وحضانة ضعيفة للرموز، ووصول إلى بيانات CRM عالية القيمة. يصبح الرمز هو السلطة.
لم تكن هذه سرقة كلمات مرور عادية
لا تزال العديد من سيناريوهات الاختراق تفترض وجود تسجيل دخول بشري. إعادة تعيين كلمة المرور، إضافة MFA، مراجعة سجل الدخول، والمضي قدمًا. تُظهر حملة Drift لماذا هذا غير كافٍ. رمز OAuth ليس مثل قيام مستخدم بكتابة كلمة مرور. يمكنه تمثيل تطبيق موثوق لديه بالفعل موافقة على الوصول إلى البيانات. ويمكنه تجاوز بعض ضوابط تسجيل الدخول البشري لأنه من المتوقع أن يستدعي واجهات برمجة التطبيقات دون وجود شخص.
هذا لا يعني أن MFA غير مهمة. يمكن لـ MFA منع اختراق المستخدم الأولي وحماية سير عمل الموافقة الإدارية. ولكن بعد وجود رمز تطبيق صالح، فإن الضوابط المهمة هي نطاقات التطبيق، وتخزين الرموز، وعمر رمز التحديث، ومراجعة التطبيق، وسرعة الإلغاء، ومراقبة API، واكتشاف شذوذ الوصول إلى البيانات. يمكن للعميل أن يكون لديه MFA بشري جيد ويظل معرضًا للخطر إذا سُرق رمز تطبيق طرف ثالث.
حذرت نشرة FBI و IC3 ذات تصنيف TLP:CLEAR،مجموعات الجرائم الإلكترونية UNC6040 و UNC6395 تخترق منصات Salesforce، من أن UNC6395 استخدمت رموز OAuth المخترقة لتطبيق Salesloft Drift وأن آلية الوصول اختلفت عن حملات أخرى استهدفت Salesforce. كما صنف تنبيهFINRA للأمن السيبراني حول هجوم سلسلة التوريد الذكي لـ Salesloft Driftالحادث للشركات المالية الخاضعة للتنظيم، قائلاً إن رموز مصادقة OAuth المسروقة سمحت للجهات المهددة بانتحال شخصية تطبيق Drift الموثوق والوصول غير المصرح به إلى بيئات العملاء.
توضح هاتان النشرتان لماذا كانت هذه مشكلة حوكمة، وليس مجرد اختراق لمورّد. كان على الشركات الخاضعة للتنظيم فحص ما إذا كان لتطبيق طرف ثالث وصول إلى بيانات Salesforce، وما إذا كانت الأسرار مخزنة في سجلات CRM، وما إذا كان العملاء أو العملاء المحتملون قد تعرضوا. أصبحت مشكلة المنصة والمورد مشكلة امتثال للعميل.
توثق وثائق Salesforce حولالتطبيقات المتصلةالنموذج الأساسي لتكامل التطبيقات الخارجية مع Salesforce. وتوضح وثائق OAuth للتطبيقات المتصلة، بما في ذلكإعدادات OAuth، سبب أهمية النطاقات والسياسات. هذه الوثائق ليست أدلة على الحادث. إنها تشرح سطح التحكم.
حولت النطاقات الثقة إلى نطاق تأثير
تحدد نطاقات OAuth ما يمكن للتطبيق فعله. في التصميم الأدنى، يحصل التطبيق فقط على الوصول اللازم لمهمة محددة. في التصميم الواسع، يمكنه قراءة أو كتابة فئات كبيرة من السجلات، واستدعاء APIs، وتحديث الوصول، والعمل عبر سطح بيانات واسع. تطرح حملة Drift سؤالاً حول ما إذا كانت راحة التكامل قد تجاوزت انضباط النطاق.
أفادت GTIG أن UNC6395 استفسر بشكل منهجي عن البيانات من بيئات Salesforce وصدرها وبحث في السجلات عن بيانات الاعتماد. هذا يعني أن التعرض لم يقتصر على قائمة حقول تملكها Salesloft. بل شمل بيانات Salesforce للعملاء التي يمكن الوصول إليها عبر التكامل. إذا كانت لدى العميل أسرار في حالات Salesforce، أو الملاحظات، أو سلاسل الدعم، أو نصوص المحادثة، أو الحقول المخصصة، أو المرفقات، فقد تصبح هذه الأسرار مرحلة الخطر التالية.
هذا فرق رئيسي عن اختراق جدول العملاء الخاص بمورّد. سمح الرمز المخترق للمهاجم بالوصول إلى بيئة Salesforce لكل عميل متصل. توقف الضرر على ما يخزنه كل عميل، وكيفية تكوين مؤسسة Salesforce الخاصة به، والكائنات التي يمكن للتطبيق الوصول إليها، وما إذا كانت الأسرار مضمنة في السجلات. يمكن لنفس فئة الرمز المسروق أن تنتج أضرارًا مختلفة عبر العملاء.
شدد تحليل AppOmni على الوقاية بين SaaS وصعوبة الرؤية عبر التطبيقات المتصلة. كما صورتنشرة الأمن لـ Arctic Wolfالحدث حول رموز OAuth المخترقة لـ Salesloft Drift وسرقة بيانات Salesforce. هذه المصادر هي تحليلات للمورّدين، لكنها تعزز نفس نقطة التحكم: تكاملات SaaS تخلق هويات غير بشرية تستحق حوكمة دورة الحياة.
يمكن أن يبدو مصطلح "الهوية غير البشرية" مجردًا. في هذا الحادث، يعني اعتماد تطبيق يمكنه التصرف دون وجود شخص على لوحة المفاتيح. قد تتم الموافقة عليه مرة واحدة ثم يستمر. قد يكون لديه وصول واسع لأن الوصول الواسع يجعل التكامل مفيدًا. قد لا يظهر في لوحات تحكم تسجيل الدخول العادية. قد يعيش أطول من عملية العمل التي بررته. وبمجرد سرقته، يمكنه التحرك بسرعة لأن استدعاءات API طبيعية لتلك الهوية.
سوق التطبيقات المتصلة جزء من سلسلة التحكم
ذكرت نشرة Salesforce أنه تمت إزالة Drift من AppExchange في انتظار المزيد من التحقيق. هذه الاستجابة مهمة لأن AppExchange ليس مجرد دليل. إنه إشارة ثقة. غالبًا ما يستنتج العملاء أن التطبيقات المدرجة في السوق قد اجتازت عملية مراجعة ومناسبة للتثبيت. السوق لا يلغي العناية الواجبة للعميل، لكنه يؤثر على اختيارات العميل.
عندما يصبح تطبيق السوق مسار وصول لحملة، فإن مسؤولية المنصة ليست أنها تسببت في اختراق المورد. المسؤولية هي أنه يجب عليها الاكتشاف والتواصل والتعطيل ومساعدة العملاء على التعافي بشكل أسرع مما يسمح به الاكتشاف كل عميل على حدة. ترى المنصة تثبيتات التطبيق عبر المستأجرين. يمكنها تحديد العملاء الذين قاموا بتثبيت التطبيق. يمكنها تنسيق إبطال الرموز. يمكنها إخطار العملاء المتضررين. يمكنها إزالة أو تعليق الإدراج. هذه الرؤية عبر العملاء هي بالضبط سبب أهمية حوكمة المنصة.
يبدو أن Salesforce استخدمت دور المنصة هذا في السجل العام: تنص نشرتها على أنها عملت مع Salesloft، وأبطلت الرموز، وأزالت التطبيق، وأخطرت المنظمات المتأثرة. سؤال المساءلة هو مدى سرعة حدوث ذلك بالنسبة لأول نشاط مشبوه وما إذا كان لدى العملاء وصول كافٍ للسجلات لتحديد تعرضهم الخاص. أبلغت GTIG عن نشاط الحملة بدءًا من 8 أغسطس. تم الإبلاغ عن إبطال الرموز في 20 أغسطس. يمكن للجمهور رؤية الفاصل الزمني التقريبي، ولكن ليس عملية قرار الاكتشاف الداخلي.
يتحمل العملاء أيضًا مسؤوليات. يختارون التطبيقات، ويوافقون على النطاقات، ويخزنون الأسرار في السجلات، ويراقبون سلوك API، ويراجعون التطبيقات المتصلة. لكن مسؤولية العميل مقيدة بإمكانيات المنصة. إذا كانت مراجعات التطبيقات المتصلة صعبة الفهم، وإذا كانت النطاقات واسعة جدًا، وإذا كانت السجلات صعبة الوصول، وإذا كان جرد الرموز مجزأً، أو إذا كانت ثقة السوق غامضة، يتخذ العملاء قرارات برؤية غير مكتملة.
لذا لا ينبغي تأطير الحادث كتمرين بسيط لإلقاء اللوم ثلاثي الاتجاهات. إنها سلسلة: كان على 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 مهمة هنا، لكن توفر السجل يختلف حسب الإصدار والتكوين والاحتفاظ ونضج العميل. لا يمكن أن تحل النشرات العامة محل الأدلة على مستوى المستأجر.
الخطوة الثانية هي تدوير الأسرار. إذا كانت السجلات تحتوي على مفاتيح 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 للتفويض المفوض. تسمح مواصفات OAuth 2.0 الأساسية،RFC 6749، للعميل بالحصول على رموز وصول إلى الموارد بتفويض من مالك المورد. التصميم قوي لأن المستخدم لا يحتاج إلى إعطاء العميل كلمة مروره. الخطر هو أن رمز الوصول غالبًا ما يكون اعتماد حامل: من يحمله يمكنه استخدامه ضمن نطاقه حتى ينتهي أو يُلغى.
تحذر اعتبارات نموذج التهديد والأمان لـ OAuth فيRFC 6819من تسرب الرموز، وتخزين الرموز، وإعادة التشغيل، والتصيد، وإساءة إعادة التوجيه، والحاجة إلى تقييد النطاق والعمر. تواصل أفضل الممارسات الأمنية الحالية لـ OAuth 2.0،RFC 9700، هذا الاتجاه من خلال التأكيد على الأنماط الدفاعية الحديثة. هذه المعايير ليست تقارير حوادث Salesforce. إنها تشرح لماذا كانت حملة Drift خطيرة هيكليًا.
إذا كان لرمز Drift وصول واسع إلى Salesforce، فإن الرمز نفسه يجسد الثقة. يمكن لفريق الأمان إزالة كلمة مرور المستخدم، وفرض MFA، ولا يزال يواجه خطرًا إذا ظل رمز التطبيق صالحًا. لهذا كان إبطال الرمز هو الإجراء الطارئ. ولهذا أيضًا فإن الطبقة التالية هي تقليل النطاق. يمكن أن يكون الرمز المسروق ذو النطاق الضيق ضارًا لكنه محدود. يمكن أن يصبح الرمز المسروق ذو وصول قراءة واسع أداة لتصدير البيانات.
تصف تقنية MITRE ATT&CKسرقة رمز وصول التطبيققيام الخصوم بسرقة رموز وصول التطبيق للوصول إلى الأنظمة البعيدة وAPIs. وتغطي تقنيتها لـاستخدام مواد مصادقة بديلةالنمط الأوسع لاستخدام أدوات مصادقة صالحة بدلاً من كلمات المرور. تساعد هذه الأطر في تسمية فئة الهجوم دون المبالغة في حقائق Salesforce الخاصة: كانت القضية هي مواد مفوضة صالحة في الأيدي الخطأ.
الدرس القياسي بسيط لكنه صعب تشغيليًا. يجب معاملة الرموز كأسرار. يجب معاملة رموز التحديث كأسرار حساسة بشكل خاص لأنها يمكن أن تصدر وصولاً مستقبليًا. يجب أن تكون النطاقات ضيقة بقدر ما يتحمله المنتج. يجب أن تكون الرموز قابلة للتدوير والإلغاء. يجب أن تظهر السجلات استخدام الرمز حسب التطبيق والكائن. يجب أن يعرف العملاء أي الهويات غير البشرية يمكنها قراءة بياناتهم. يجب أن تجعل المنصات الموافقة على النطاقات الخطيرة صامتة صعبة.
نظافة التطبيقات المتصلة تحتاج إلى مالك، وليس جدول بيانات بعد الاختراق
تكتشف العديد من المنظمات تطبيقاتها المتصلة أثناء الحادث. هذا متأخر جدًا. يجب أن يوجد جرد للتطبيقات المتصلة قبل الحملة: اسم التطبيق، المورد، المالك التجاري، المالك التقني، النطاقات، الملفات الشخصية المثبتة، آخر استخدام، سياسة رمز التحديث، كائنات البيانات التي يلمسها، حالة العقد، وإجراء الإزالة. إذا لم يمتلك أحد التطبيق، لا يمتلك أحد المخاطر.
توضح وثائق Salesforceلإدارة التطبيقات المتصلةوسياسات OAuth للتطبيقات المتصلةأن المنصة تقدم ضوابط إدارية. السؤال هو ما إذا كان لدى العملاء الموظفون والمعرفة والحوافز لاستخدامها بشكل جيد. قد تقوم شركة صغيرة بتثبيت أداة محادثة مبيعات ولا تعيد النظر في نطاقاتها أبدًا. قد يكون لدى مؤسسة كبيرة مئات التطبيقات المتصلة ولا يوجد إيقاع مراجعة موحد.
هنا يجب أن يقلل تصميم المنصة من الخطأ. يجب أن تكون النطاقات الخطيرة مرئية بلغة واضحة. يجب أن يكون من السهل العثور على التطبيقات المتصلة غير المستخدمة. يجب إبراز التطبيقات التي تحتوي على رموز تحديث. يجب أن يكون للتطبيقات عالية المخاطر خيارات انتهاء صلاحية أو إعادة تفويض دورية. يجب أن يكون المسؤولون قادرين على إلغاء وصول التطبيق دون كسر سير العمل غير المرتبط. يجب أن تتلقى فرق الأمان تنبيهات شذوذ API خاصة بالتطبيق.
يحتاج العملاء أيضًا إلى سياسة. لا ينبغي أن يتلقى أي تطبيق وصولاً واسعًا بدون مالك مسمى وتاريخ مراجعة. لا ينبغي أن يبقى أي تطبيق مثبتًا بعد مغادرة المالك التجاري. لا ينبغي أن يخزن أي تطبيق أسرارًا في سجلات CRM لمجرد أنها مريحة. لا ينبغي أن يُستثنى أي تطبيق من سيناريوهات الحوادث لأنه "مجرد أداة مبيعات". أظهرت حملة Drift أن أداة المبيعات يمكن أن تصبح مسار حادث أمني.
المشكلة اقتصادية جزئيًا. توفر التطبيقات المتصلة العمالة. تكلف المراجعة العمالة. إذا كانت الفائدة فورية والمخاطر نادرة، تستثمر المنظمات بأقل من اللازم في المراجعة. يمكن للمنصة والمورد تقليل هذا الاختلال من خلال خفض تكلفة الحوكمة الجيدة: لوحات تحكم واضحة، نقاط مخاطر، توصيات آلية، وإعدادات افتراضية أكثر أمانًا.
يجب أن تجيب السجلات على أسئلة يمكن للعميل التصرف بناءً عليها
غالبًا ما تخبر إرشادات الحوادث العملاء بمراجعة السجلات. هذه النصيحة مفيدة فقط إذا أجابت السجلات على الأسئلة الصحيحة. بالنسبة لحملة Drift، احتاج العملاء إلى معرفة أي رموز تطبيق تم استخدامها، وأي كائنات Salesforce تم الاستعلام عنها، وأي سجلات تم تصديرها، ومن أي IPs، وبأي سياق مستخدم، خلال أي نافذة زمنية، وما إذا كانت الاستعلامات تبحث عن سلاسل تشبه الأسرار.
يمكن أن تساعد مراقبة أحداث 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 هذه الواجبات مرئية بأكثر طريقة غير مريحة: بتحويل تكامل إنتاجية معتمد إلى مفتاح بحوزة المهاجم.