حوّلت DigitalOcean حادثة بائع بريد إلكتروني تسويقي إلى اختبار مساءلة لعملاء السحابة

ملخص

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

سجل الأدلة وكيفية استخدامه

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

لماذا أصبحت حادثة البريد التسويقي حادثة حساب سحابي

من السهل التقليل من أهمية حادثة Mailchimp لـ DigitalOcean في 2022 إذا نظر القارئ فقط إلى تسمية "البريد التسويقي". عنوان البريد الإلكتروني لعميل السحابة ليس كلمة مرور رئيسية أو مفتاح SSH أو رمز API أو لقطة قاعدة بيانات. لكنه ليس ضارًا أيضًا. بالنسبة لمنصة سحابية، غالبًا ما يكون عنوان البريد الإلكتروني هو معرف تسجيل الدخول، ووجهة إعادة تعيين كلمة المرور، وقناة تنبيهات تسجيل الدخول غير المعتادة، ومكان وصول تحذيرات الفوترة، والطريقة التي تتعلم بها الفرق الصغيرة أن موردًا أو رمزًا أو قطرة أو نطاقًا أو تذكرة دعم تحتاج إلى اهتمام. بمجرد كشف هذا العنوان مع معرفة أن الشخص عميل DigitalOcean، لا يحتاج المهاجم إلى حملة تصيد واسعة.

يمكن للمهاجم محاولة إعادة تعيين كلمة مرور DigitalOcean، أو تقليد إشعارات المنصة، أو استهداف مسؤول سحابة معروف، أو البحث عن عوامل ثانية ضعيفة.

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

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

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

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

ما قالت DigitalOcean أنه حدث

يبدأ الحساب العام لـ DigitalOcean مع تسليم البريد الإلكتروني. في الساعة 3:30 مساءً بالتوقيت الشرقي يوم 8 أغسطس 2022، قالت الشركة أن رسائل البريد الإلكتروني المعاملاتية من منصة DigitalOcean التي يتم تسليمها عبر Mailchimp توقفت عن الوصول إلى صناديق البريد الوارد للعملاء. لم تكن الأمثلة مجرد حملات ترويجية. شملت تأكيدات الحساب وإعادة تعيين كلمة المرور ورسائل التنبيه والرسائل المتعلقة بالمنتج. قالت DigitalOcean أنها اكتشفت المشكلة من خلال فحص هندسي على صحة التسجيل ووجدت أن حساب Mailchimp الخاص بها قد تم تعليقه دون وصول ودون تفاصيل مفيدة من البائع في ذلك الوقت.

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

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

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

ما قالته Mailchimp، ولماذا إطار البائع غير مكتمل لعملاء السحابة

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

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

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

لم يثبت بيان Mailchimp نفسه كل تأثير لاحق على مستخدمي DigitalOcean. لم يثبت بيان DigitalOcean كل تفاصيل خاصة حول بيئة Mailchimp. قراءة جدية للمساءلة لا تملأ تلك الفجوات بالتخمين. تسأل أي طرف كان في موقف يعرف ماذا: Mailchimp تحكمت في سجلات وصول البائع وأدلة أدوات الدعم؛ DigitalOcean تحكمت في تلميترية أمن حسابها الخاص وإشعارات العملاء؛ العملاء تحكموا في عواملهم وكلمات المرور وعضوية الفريق وسجلات الموارد. كان على الأدلة أن تنتقل عبر تلك الحدود بسرعة كافية لدعم الإجراء.

قوائم البريد الإلكتروني للعملاء هي أصول أمنية عندما تحدد مسؤولي السحابة

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

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

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

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

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

البريد المعاملاتي جزء من مسار الاسترداد

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

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

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

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

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

محاولات إعادة تعيين كلمة المرور حولت التعرض إلى عمل استجابة

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

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

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

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

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

مراجعة وصول البائع هي ضابط مزود سحابة، وليست شكليات شرائية

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

ما مدى السرعة التي يمكن أن تنقل بها DigitalOcean الرسائل الحرجة إلى مزود آخر؟

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

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

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

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

خطر التصيد هو عمل، وليس مجرد شعار توعية

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

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

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

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

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

ما تحكم فيه العملاء بعد الإشعار

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

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

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

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

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

ما تحكمت فيه DigitalOcean بعد الإشعار

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

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

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

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

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

ما تحكمت فيه Mailchimp

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

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

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

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

لم تكن Mailchimp مزود السحابة. لم تتحكم في أمن وحدة تحكم DigitalOcean. لكنها تحكمت في نظام لامس عملاء DigitalOcean على حافة الحساب. هذا كافٍ لخلق واجب أدلة مشترك.

اقتصاديات جهة اتصال الإساءة والتكلفة الخفية للقوائم المستهدفة

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

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

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

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

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

الأدلة التي تفصل تعرض البريد الإلكتروني عن اختراق الموارد السحابية

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

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

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

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

هذا هو المكان الذي تساعد فيه لغة المعايير. وظائف NIST للتحديد والحماية والكشف والاستجابة والتعافي ليست تسميات زخرفية. تصف سلسلة الأدلة: معرفة أي الأصول والأطراف الثالثة مهمة؛ حماية الحسابات ومسارات الاتصال؛ كشف نشاط إعادة التعيين المشبوه وتسجيل الدخول؛ الاستجابة بإشعارات محددة واحتواء؛ استعادة الثقة في الاتصال وضوابط الحساب. ضوابط CIS تعطي فئات عملية مماثلة حول المخزون والحسابات والوصول والسجلات. قضية DigitalOcean-Mailchimp هي حادثة صغيرة فقط إذا عملت تلك الفئات.

أسئلة الحوكمة لمزودي السحابة والمشترين

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

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

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

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

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

نتيجة المساءلة

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

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

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

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

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